From luisc@it.uc3m.es Sun Nov 1 04:59:34 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B393A6852 for ; Sun, 1 Nov 2009 04:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peccVCrwovAI for ; Sun, 1 Nov 2009 04:59:33 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 79A203A6358 for ; Sun, 1 Nov 2009 04:59:33 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 31AE6BA83AD; Sun, 1 Nov 2009 13:59:50 +0100 (CET) Received: from 106.pool85-49-206.dynamic.orange.es (106.pool85-49-206.dynamic.orange.es [85.49.206.106]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Sun, 01 Nov 2009 13:59:48 +0100 Message-ID: <20091101135948.qmgnb7zw80k0wwg8@webcartero01.uc3m.es> Date: Sun, 01 Nov 2009 13:59:48 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4AEB5B09.3060907@venaas.com> <4AEB62D6.4030105@fhtw-berlin.de> In-Reply-To: <4AEB62D6.4030105@fhtw-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16982.007 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] Proposals and charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 12:59:34 -0000 Hi all, I think that draft-contreras-multimob-msd-00 can fit also into the category of "dedicated multicast LMA" when the MAG operates as MLD proxy and the upstream interface is defined over the tunnel between the MAG and the LMA, as mentioned in section 6.1. The draft considers just one MLD proxy instance per MAG, that is the case of "dedicated multicast LMA" category. Additionally, draft-contreras-multimob-msd-00 presents a handover support method which is applicable for all cases. I think it could be considered as input for both proposal categories under evaluation. Best regards, Luis "Thomas C. Schmidt" dijo: > Hi Stig, > > if I overlook proposals correctly, there are three contributions that > comply to the charter: > > [Direct Routing Option:] > If native multicast routing reaches all MAGs in a PMIP domain, then > straight-forward MLD proxying can be applied at MAGs with neither > participation of the LMAs, nor tunneling. > This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if > you strip context transfer and predictive operations off the document. > > [Dedicated Multicast LMA:] > If all multicast traffic of an entire PMIP domain is managed by a > single LMA, then all MAGs may choose a tunnel with this particular > LMA for multicast uplink. There is no need for proxy binding caches > and MN-specific states at the LMA. > This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], > if you strip handover-specifics off the document. > > [Proxy instance per LMA:] > If multicast traffic in PMIP should follow unicast paths, then it > arrives at the MN via MN-specific LMAs and MAGs on the basis of proxy > binding caches. This approach is a direct extension of unicast, > facilitated by placing a proxy instance per MAG-LMA uplink on MAGs > and proposed in [draft-schmidt-multimob-pmipv6-mcast-deployment]. > > From my understanding of the available documents, no further > contributions exist that comply to the charter (i.e., do not change > PMIP or multicast protocols, or the processing/semantics at > corresponding routers). > > Hope that clarifies the field ;) > > Cheers, > > Thomas > > > Stig Venaas wrote: >> The main goal of our meeting in Hiroshima is to see if we can adopt >> documents for our charter work items. In addition to the technical >> evaluation, we also need to consider whether documents are within our >> charter. Either whether the document is currently within the charter, >> or if it can easily be updated to be within the charter. >> >> For PMIP, we have the following milestone: >> >> Nov 2009 Initial version of a document explaining the use of multicast >> in PMIPv6 >> >> It might be good to get some discussion on the list prior to the meeting >> to see which proposals may be within the charter and a candidate for >> this. We will certainly be discussing this in the meeting, but by having >> some discussion and analysis on the mailing list before the meeting, we >> may be able to have a better discussion at the meeting itself. >> >> You should all read the charter at >> http://www.ietf.org/dyn/wg/charter/multimob-charter.html >> >> Some of the important points related to PMIP (this may not be a full >> list, so read the charter itself) are: >> >> 1. Work requiring modifications to mobility protocols and IGMPv3/MLDv2 >> is out of scope in this first stage of this working group. >> Modifications to multicast routing protocols are out of scope. >> >> 2. This work will not require any additions or changes to message types >> and parameters specified in RFC 5213, >> >> 3. and must assume an unmodified mobile host. >> >> 4. The work will employ the remote subscription model. This is a >> mechanism by which a mobile node joins a multicast group and >> receives multicast data forwarded via the local mobility anchor. >> >> I hope I've given managed to point out the main points in the charter in >> a fair way. It's the charter text itself that is important, not what I >> write here though. >> >> I now hope we can get some discussion on whether the different proposals >> match the points above, or if you like, the charter text. >> >> Stig, co-chair hat on >> _______________________________________________ >> 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Luis M. Contreras Profesor Asociado Dpto. de Ingenier=EDa Telem=E1tica Universidad Carlos III de Madrid ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Guang.Lu@InterDigital.com Sun Nov 1 20:25:59 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41E63A6851 for ; Sun, 1 Nov 2009 20:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnZeHsli4QjT for ; Sun, 1 Nov 2009 20:25:58 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 8E2903A6781 for ; Sun, 1 Nov 2009 20:25:58 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 23:26:17 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 23:26:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Nov 2009 23:26:12 -0500 Message-ID: In-Reply-To: <4AEC3AAE.4060104@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Comments on draft-zuniga-multimob-smspmip-00 Thread-Index: AcpaLZLk0Lwi6kMLToS6MdOUeZu89gBRREJA References: <20091028105641.kckn9rzfkgkokoos@webcartero01.uc3m.es> <4AEB5C6C.8000507@informatik.haw-hamburg.de> <20091031131852.ttdjc5xhj404gg8c@webcartero01.uc3m.es> <4AEC3AAE.4060104@informatik.haw-hamburg.de> From: "Lu, Guang" To: X-OriginalArrivalTime: 02 Nov 2009 04:26:17.0187 (UTC) FILETIME=[9ECA4330:01CA5B74] Subject: Re: [multimob] Comments on draft-zuniga-multimob-smspmip-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 04:25:59 -0000 Hi Thomas and Luis,=20 Thank both of you for bringing in the constructive discussions. Please = see my input.=20 Thanks, Guang > -----Original Message----- > From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Sent: Saturday, October 31, 2009 9:25 AM > To: Luis M. Contreras > Cc: multimob@ietf.org; Lu, Guang > Subject: Re: [multimob] Comments on draft-zuniga-multimob-smspmip-00 >=20 > Hi Luis, >=20 > O.K. - you caught me by being too fast ;) >=20 > The issue nevertheless is only the name "LMA" I guess ... see below: >=20 > Luis M. Contreras wrote: >=20 > > My answer below: > > > >>>> Section 4 presents the architecture of the dedicated LMA > multicast. I > >>>> have two questions on this: > >>>> - Both LMAs (unicast and multicast) keep the same information in > their > >>>> respective binding caches? How can be guaranteed the coherence of > the > >>>> information contained in both binding caches? > >>> [Guang-JC] Both unicast and multicast LMAs serve independent sets > of MNs > >>> so they can have different binding caches. On the other hand, if = an > MN > >>> has both the unicast LMA and multicast LMA in its policy profile, > the > >>> MAG will do the Binding Update to unicast LMA and multicast LMA > >>> independently. > >> [Thomas] There is no need for a binding cache here, as - according > to > >> the draft - there is only a single MLD proxy instance, thus a = single > >> uplink and therefore only a single multicast LMA. All MAGs > throughout > >> the PMIP domain MUST share the uplink for multicast with this > >> particular LMA. The LMA will thus forward according to > >> (proxy-initiated) forwarding states at its tunnel interfaces that > are > >> independent of individual MNs. > >> > > [Luis] According to RFC5213, section 3, the actions taken by the LMA > > once it receives tha PBU message from the MAG are: "Upon accepting > this > > Proxy Binding Update message, the local mobility anchor sends a = Proxy > > Binding Acknowledgement message including the mobile node's home > network > > prefix(es). It also creates the Binding Cache entry and sets up its > > endpoint of the bi-directional tunnel to the mobile access gateway." > So, > > if the way of registering in the multicast-dedicated LMA is the > standard > > PBU/PBA procedure, a binding cache should be created and maintained > for > > the MN there. If not, we are altering the protocol specified in > RFC5213. > > Maybe this is an extreme interpretation by myself. > > >=20 > [Thomas] I agree, you are perfectly right, as long as we call this > multicast thing "LMA". If we just call it a multicast designated > router, > then no binding procedures with the MN ("A receiver") are required. In > fact, an MLD proxy is supposed to aggregate states ... and a multicast > router is supposed to maintain only 'anonymous' forwarding states at > its > downstream interfaces (towards the MAGs). That actually would make > things much easier and reduces protocol operations to what is really > needed. >=20 > > Furthermore something could be said regarding the reference in > RFC5213 > > to the mobile node's home network prefix(es). I think that if the > > procedure is not the same for LMA multicast than for LMA unicast we > are > > then defining a bit different signalling procedure . > > >=20 > [Thomas] The home network prefix(es) and all other *unicast*-related > states of the MN's profile should be maintained by the (untouched) > unicast entities: there will be an LMA operating unicast mobility as > described in RFC5213 ... in this proposal, multicast comes as an > "additional overlay", unseen by the 'standard LMAs', I believe. >=20 > Am I understanding things correctly? [Guang-JC] Your interpretation in the paragraph above is in-line with = our reply on this comment. Please see embedded above.=20 >=20 > Best regards, >=20 > Thomas > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor > 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875- > 8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875- > 8409 =B0 From behcetsarikaya@yahoo.com Wed Nov 4 07:32:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2E73A6358 for ; Wed, 4 Nov 2009 07:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, FRT_POSSIBLE=2.697, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWpMcqvtEJ82 for ; Wed, 4 Nov 2009 07:32:08 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id C47753A6904 for ; Wed, 4 Nov 2009 07:32:08 -0800 (PST) Received: (qmail 51394 invoked by uid 60001); 4 Nov 2009 15:32:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1257348749; bh=a03RTRVKoY3VW1jolQLulUOA5eLOMNrRq/wID6BgVSY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YFAS4HCx5YRcJUVN5xxw/gfN2rVIeUbDsnqFSxSiG23KyxtwdE6Q62Zjal7+T8g7EEdG/COtU4Fp94/4f35htDa4x2u/f2uUJvIyWQV2lK4u8qAsLWr38sLiPnX5z90YEJw2i3WACjn7nF2sH59DTJDoUAk1hE+ybL1FEWVvW2A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TaYJaItZET0jh2ymPlkeSTnQx56LZGhfn6xVjJ2A3moZQe3kBQTs/DcjIIhLrwOBt0Dc6ZY8q0cUSJA3ZPczl9auESgh9WmLBvfIcI3tLryBqlWzcEm2CnJkC9B0iaPaWjWN/ztzSpoSPZdVBkIxPM7IqrXBQMrut6Mwf7DJ064=; Message-ID: <28014.41929.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: RIi_9tgVM1mqRc0qRp7gRWTaQFNhJ1rUaxHVeU9lgK5nGiYFZQvxBWM2QrvhUzPlPDlMRfhilVwdeIF3FEQdvcz8OhlreTIPK2BjF.A68LpMTBOZvz5WTtXZ0pGeb4Rsy.W85CH_DhoFuD7RdaHZ28PcMu0Bl4zYrQDoBiuw_joeYaX69MccFrueqFM8P.NwF1HZ5hKIYL1FEY.cAHiuQIKzqQRtBKcgl1993li7yLDNajLdz7W2cbGzUP4vn_TqvK5ZXICplAuWlt5A5_Haj0CGx.U7.fknGVQf3BPCQIdVSkOxdNgn5R_XXywZ24MqdwqYwGiyfHZp1ifFISchguA- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 04 Nov 2009 07:32:28 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Wed, 4 Nov 2009 07:32:28 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Some comments on draft-asaeda-multimob-igmp-mld-optimization-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:32:09 -0000 =A0I am forwarding Hitoshi's reply which somehow got stuck somewhere.=0A=0A= --behcet=0A=0A>Stig,=0A> =0A> > I've had a quick read of this draft and hav= e some comments.=0A> > =0A> > 1. Lightweight IGMPv3/MLDv2=0A> > =0A> >=A0= =A0=A0 There is some discussion on this that I don't think is very=0A> >=A0= =A0=A0 relevant to multimob. Whether to implement the lightweight or=0A> >= =A0=A0=A0 regular version is IMO entirely a host stack implementation=0A> >= =A0=A0=A0 issue. It does not influence PMIP or the network infrastructure.= =0A> =0A> An important point we need to know is that there is no applicatio= n=0A> using an EXCLUDE (S,G) operation. This draft aims to contribute to a= =0A> guideline for mobile terminal and router implementations and=0A> confi= gurations; hence describing the advantage of LW protocols is one=0A> of the= task of this draft. This is my thought.=0A> =0A> Additionally, it is obvio= us that an EXCLUDE mode operation does=0A> influence the routing infrastruc= ture. Imagine that what happens if=0A> some of mobile nodes join EXCLUDE (S= ,G) when others join INCLUDE (S,G).=0A> Upstream mobile router just switche= s SPT to RPT for that EXCLUDE (S,G)=0A> request. The EXCLUDE join just brea= ks SSM communication.=0A> Of course, it'll be happened even with (*,G) join= . However EXCLUDE=0A> (S,G) join does not create any benefit, and requires = more complex=0A> states than (*,G) join state in routers.=0A> In summary, E= XCLUDE (S,G) join gives the high possibility of unwilling=0A> routing condi= tion. To eliminate the possibile worse scenario that an=0A> EXCLUDE operaio= n is misused or used by malicious users, I would highly=0A> recommend the u= se of LW-IGMPv3/MLDv2.=0A> =0A> >=A0=A0=A0 At least not as long as we also = need to support the regular=0A> >=A0=A0=A0 versions. I see benefits with th= e lightweight mode, but not for=0A> >=A0=A0=A0 us.=0A> =0A> While I don't d= eny to support the standard IGMPv3/MLDv2 in this draft,=0A> because of abov= e thoughts, I propose to recommend to use=0A> LW-IGMPv3/MLDv2 for mobile co= mmunications.=0A> =0A> > 2. Unsolicited notifications (MLD reports)=0A> > = =0A> >=A0=A0=A0 This may be useful, but I think this is a change in protoco= l. So=0A> >=A0=A0=A0 at least with respect to our charter item for a docume= nt on tuning=0A> >=A0=A0=A0 IGMPv3/MLDv2 I think this goes to far. It is mo= re than just tuning.=0A> =0A> If it is the concensus of this WG, I move the= statements to my=0A> extension draft for future.=0A> =0A> > 3. Unicast of = General Queries=0A> > =0A> >=A0=A0=A0 This is interesting and according to = MLDv2 specifications, hosts=0A> >=A0=A0=A0 MUST respond to these. It would = be interesting to verify whether=0A> >=A0=A0=A0 implementations generally s= upport this. I think this can be useful,=0A> >=A0=A0=A0 but there are also = scenarios where I believe multicasting them is=0A> >=A0=A0=A0 better. I thi= nk this is a change in the protocol, at least from a=0A> >=A0=A0=A0 router = perspective, so this also goes a bit beyond what we are=0A> >=A0=A0=A0 aski= ng for in the charter right now. It could perhaps be optional=0A> >=A0=A0= =A0 behavior...=0A> =0A> This draft does not deny multicasting general quer= y at all. The=0A> advantage of unicasting general query is dependent on man= y factors,=0A> e.g. the number of active and non-active nodes attached on a= wireless=0A> link, the amount of active traffic on a link, and so on. They= are very=0A> dynamic in nature. What we need to understand in this draft i= s that we=0A> have possibile ideas to optimize the IGMP/MLD communication c= ondition=0A> by several means. But if removing this section and moving this= context=0A> to my extension draft are the concensus in this WG, I'll follo= w the=0A> decision.=0A> =0A> (I confuse the meaning of this draft if I remo= ve all of above.:)=0A> =0A> > 4. It's not clear to me, but it looks like no= tifications from the host=0A> >=A0=A0=A0 are also unicast? MLDv2 routers ar= e not required to accept unicast=0A> >=A0=A0=A0 MLDv2 reports.=0A> =0A> No,= it should be multicast. I didn't mention the IP destination=0A> address fo= r this operation, hence will do it in the next revision.=0A> Thanks.=0A> = =0A> > 5. In 3.2 regarding responding to general queries, it says:=0A> >=A0= =A0=A0 "Only the active hosts that have bee receiving multicast contents=0A= > >=A0=A0=A0 should respond the Query message." Hosts are however required = to=0A> >=A0=A0=A0 send MLD reports for e.g. the solicited node multicast ad= dress.=0A> =0A> This section mentions "IGMP/MLD guery processing", so I tho= ught this=0A> statements does not deny anything about ND or other multicast= related=0A> communication.=0A> But if it's better to clearly mentioning;= =0A> "Only the active hosts that have been receiving multicast contents=0A>= should respond the IGMP/MLD Query messages"=0A> is better, I'll do it in t= he revised version.=0A> Does this make sense?=0A> =0A> > 6. Tuning of IGMPv= 3/MLDv2=0A> > =0A> >=A0=A0=A0 Based on our charter, we want a document on h= ow to tune IGMPv3/MLDv2=0A> >=A0=A0=A0 for mobile environments. Regarding t= his, the document mostly says=0A> >=A0=A0=A0 that results will be provided = in the future.=0A> > =0A> > All in all, I think this document has some inte= resting ideas, but as=0A> > it=0A> > is today, it doesn't fit our current c= harter milestones very well.=0A> =0A> If the charter requires to define onl= y the definitive optimized timer=0A> values for each query to fit any kind = of situation, it is too=0A> optimistic to fulfill such requirement.=0A> =0A= > Again, network condition and user condition are highly dynamic. And=0A> t= he network condition would be very different in various wireless=0A> link t= ypes. Showing the best definitive timer values are the real=0A> challenge.= =0A> I prefer to at first describe the architectural scenarios of mobile=0A= > multicast and then start discussion about relation between=0A> considerab= le conditions and each timer value if possible.=0A> =0A> > I'm hoping to ge= t some discussion on these points and more reviews of=0A> > the document. W= hat do you think Hitoshi-san?=0A> =0A> If someone will be able to show some= or all of the best definitive=0A> timer values in common, I'm glad to coop= erate with them for the=0A> revised draft.=0A> =0A> Regards,=0A> --=0A> Hit= oshi Asaeda=0A=0A=0A From asaeda@sfc.wide.ad.jp Thu Nov 5 00:38:04 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6044728C1A5 for ; Thu, 5 Nov 2009 00:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1hRmi5nyXRg for ; Thu, 5 Nov 2009 00:38:03 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 51AB428C1A3 for ; Thu, 5 Nov 2009 00:38:02 -0800 (PST) Received: from localhost (wifi-139-237.sfc.wide.ad.jp [203.178.139.237]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 34DD113D06C4; Thu, 5 Nov 2009 17:38:24 +0900 (JST) Date: Thu, 05 Nov 2009 17:38:22 +0900 (JST) Message-Id: <20091105.173822.56296473.asaeda@sfc.wide.ad.jp> To: schmidt@fhtw-berlin.de From: Hitoshi Asaeda In-Reply-To: <4AE8E779.7030901@fhtw-berlin.de> References: <4AE8CC2B.1000509@venaas.com> <4AE8E779.7030901@fhtw-berlin.de> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: behcetsarikaya@yahoo.com, multimob@ietf.org Subject: Re: [multimob] Some comments on draft-asaeda-multimob-igmp-mld-optimization-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 08:38:04 -0000 Thomas, > Also, the issues and requirement on MN handover operations got > somewhat lost in this document: In the mobility regime, IGMP/MLD are > important to facilitate seamless listener handovers. Suppressing > queries or delaying times may do significant harm here. Overall, > there is an ambiguity on preserving resources on the one hand, and > ensuring service on the other. It's not that simple! Frequent query with shorter timer SHOULD NOT be adopted for fast handover. It does NOT give great benefit or rather gives heavy wireless resource usage. Just flooding query messages with shorter period is the real harm. Instead, take new context transfer mechanism for fast handover, but it is not the target of this draft. > *Scope*: Even though the charter emphasizes IGMPv3/MLDv2, I'm > still not convinced why we should exclude the widespread previous > standards ... > But in particular, I don't see any natural relation to > MLD-light. MLD-light may be standardized elsewhere and addresses > different (switching) issues. There is no need to tie mobility to > MLD-light. It might even appear that the exclude mode is of > particular interest to the mobility regime, where a receiver might > want to reject a source that exhausts its resources. So I would > suggest to cut out MLD light completely. Read my reply mail to Stig. > *Explicit tracking*: This is a well known thing (already described > in RFC 3810) and undoubtedly useful. However, it has to cope with > the uncertainty about states after handovers. So it would be helpful > to explore the design space in between the two driving forces, not > just look at one. Don't send or flood frequent query messages, and study context transfer for fast handover. > Btw: I don't understand your 4th bullet point; "It is impossible to > identify mobile hosts when hosts have the same IPv6 link-local > address in some mobile routing environment such as PMIPv6" Link-local address is not always ensured if DAD is omitted or failed. > *Section 3.2* This essentially proposes protocol changes (switch > to unicast) ... It'd be configuration matter. Need opinion from router venders. > *Section 3.3* I don't see the issue, the discussion and the > consequences (don't use explicit tracking) here ... I tend to > suggest to cut it out. No reasonable explanation. Need more opinion from others. > *Section 3.4* This section only advertises MLD-light, so IMHO it > is obsolete. Not true. Need more opinion from others. > *section 4* This section changes MLD, so it is obsolete for > now. What obsolete? This section may be moved to my extension draft if concensus, though. > However, it proposes an interesting transition from > router/network-initiated reports to MN-initiated reports. Still, > this does not appear mature to me. If an MN - unaware of its current > handoff state - issues MLD reports at a frequency compliant to > seamless handovers (say every 10 ms), then it annoys the network > continuously. On the other hand, how do you want to detect > ungraceful leaves? By erasing notes that have not reported for x*10 > ms? Again I believe it is not that simple. If this section may be moved to my extension draft, the following comments are not relevant, but I answer your question here. You said "say every 10 ms", but this assumption is very bad. I guess your assumption comes from the point of fast handover again, but it should not. I don't know what timer value is the best but it'd be a half of or a little less than a half of the default general query timer (which is 10 sec.) in my current feeling. For ungraceful leave, a router captures the MN's condition by regular query. This draft does not eliminate general query. > *section 5* You identify some of the ambiguous issues, but do not > provide counter measures. In particular, you identify compatibility > problems with your approach. Sorry, I cannot understand what you mean.. > *section 6* Essentially empty. Please read my mail replied to Stig. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Nov 5 15:34:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2ED3A681B for ; Thu, 5 Nov 2009 15:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[AWL=-2.013, BAYES_95=3, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGb4lGYMFYdj for ; Thu, 5 Nov 2009 15:34:47 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id F125928C14D for ; Thu, 5 Nov 2009 15:34:44 -0800 (PST) Received: (qmail 71156 invoked by uid 60001); 5 Nov 2009 23:35:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1257464105; bh=MOfQd5yaLGcWsHzXdbi3p0Q54cseTwmJ4Zuh1N5Zi30=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5i8ywrOMUgnGao2T8eS9lMAKVPLOIbas+Kg1V0lFFvkVhh9LMHXlWYL27q32dHFGSv+ayKyyq/V8KuwZYjE1lU2TYu1E0jDXM8REpxaav5iRpAkmxpoO9swsL7DYpff84n+6NIWG0myIHekZFSznnMvE2XYP+zN6yTSFIxtVLCE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rfQC7MklmXbPDL8Frgksyz5uIP3iBw8F6cNsvfy6lhiXkL3LvB3Tvm9xNxyj5l1uq5dUmjzWErTpWwhJ+HDihOZiDogmJi4tagAFLnptL+ZNlLRTtUr9ABRBbp5C1k16+yh7AfRY9QboAH1ReyDFr3beW/jcmtULgW4BdCFPDNg=; Message-ID: <439761.69531.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: TUuqgxIVM1m.1MuJ7KKxb26IRTUmuCytfKGqfZZgPXFS0y8o0utgFQXUx1LR2U5jFA7Q_K7QUsWCKPC4uQkg_xseIGFjqh2TT2Lvr.Y3_Nbc5sjiJJ8XnOaoJjWefi7gpuaC_c4IrRKPs5R5uZN9EZzWVtqrtAq0rzEr6Zt2LeUmpDGTt1AvIGgAKpXUXP_XHe4O7G1DzB4V1LvVfsrIOUQjsu7_J1w1Ax0qUIZO98ekLD5VyuXo_2lH2STpUt8fj4HEVFKTsIC689tzVbrviPJldu4qc5jskYli.Dbr6QlxDa76EitK0HfqPQBmPzDM9yrxbnd2RAZHCXmDO105JBYBd2g- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Thu, 05 Nov 2009 15:35:05 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Thu, 5 Nov 2009 15:35:05 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Presentations X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:34:47 -0000 Hello all,=0A=A0 Folks who are presenting next week, please send the slides= to the chairs ASAP. So far only Dirk sent his presentation.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A From waehlisch@ieee.org Mon Nov 9 06:38:33 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDFB3A6B85 for ; Mon, 9 Nov 2009 06:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.835 X-Spam-Level: X-Spam-Status: No, score=-99.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWBYDhWkHtVW for ; Mon, 9 Nov 2009 06:38:32 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D066A3A6B7D for ; Mon, 9 Nov 2009 06:38:31 -0800 (PST) Envelope-to: multimob@ietf.org Received: from host-205-166.meeting.ietf.org ([133.93.205.166] helo=mw-thinkpad.hotel.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1N7VOR-000NVa-Ix for multimob@ietf.org; Mon, 09 Nov 2009 15:38:56 +0100 Date: Mon, 9 Nov 2009 23:38:57 +0900 (Tokio Normalzeit) From: Matthias Waehlisch To: multimob@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] Draft pmip6basicmcast & TTL X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:38:33 -0000 Hi Behcet, the idea of your draft is to tunnel MLD packets from the MAG to the LMA. How does this comply with the hop limit of 1 for MLD packets? The TTL of a MLD packet should be decremented (at the MAG) and thus discarded. Thanks matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From behcetsarikaya@yahoo.com Tue Nov 10 16:15:22 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9B13A6828 for ; Tue, 10 Nov 2009 16:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mef6ZLD+kwtl for ; Tue, 10 Nov 2009 16:15:21 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id ACA4D3A69CA for ; Tue, 10 Nov 2009 16:15:21 -0800 (PST) Received: (qmail 74481 invoked by uid 60001); 11 Nov 2009 00:15:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1257898546; bh=WsPv0F8pkIF3u4w/doDwnH26PxSx+ZAo/KEMDtw3JRc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pDWppYVeJlla2dSTdn0fYxjOwL0ua5XX5+GUGKKoepgd+UmxflkGD7+1XxOhjS+YFbFbezCeUS8/GCfYMUYKaBr4FAx7NVWINse+VGU2E+T8Sutp39sqHhtECAlKxowk3UxyIAdXm0NN2oHkdOqRdMS5f/8Vdb4J4qR+jGjizmw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HI+lqtB1+cKkIuiLgAn6Wai4vRWSrt6o7dRDdXovY7rpuN6LL+mLkb69uCREjbX21pZ8/4RB2XGO1yGCJGN7YQTwYy9cPuM/In6c7/cedsi2GpSbkvr04hugSTroXi3pLoFbPSy67HtOy+eiQPPanR9xBDC3WbCouvyPtQjrEqs=; Message-ID: <947204.74431.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: 6tD8G8cVM1nkv0GjsKOHiWjIFKwz9oQ9QC3vfdl2Yp1zNqOjh14qfwaYy5v2ZCh9d9fo2ymW7tSwUAOxPg8N1HjQXLBe_GVPpZV1KRDzO69E60sh4MmOSFI4jjwpSIV8d3VhhjkmmuP5kbkkYwOiGIU8.hJlA86NbPPo_.U2IWMwdNklAu8WsOuPNdr2NSTYBDKtqHEFQArquWaQTDQstQDUs6A.L98jP2cPrXQ_z1W4pKWPJqeRxh2ohKmZHdN1KvNmTOfhNRDFeeTlp6NaUU6V3IYRR9DfnCtWQTIHHbZD7TWI9g-- Received: from [133.93.25.69] by web111410.mail.gq1.yahoo.com via HTTP; Tue, 10 Nov 2009 16:15:46 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Tue, 10 Nov 2009 16:15:46 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Presentations X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:15:22 -0000 Hello all,=0A=A0 We now have all presentations uploaded,=0A=0A=0Aexcept=0A= =0A=0AHitoshi's presentation.=0A=0AHitoshi, please send your slides asap.= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From asaeda@sfc.wide.ad.jp Tue Nov 10 16:37:20 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071A63A691A for ; Tue, 10 Nov 2009 16:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5zD3q2J0uiL for ; Tue, 10 Nov 2009 16:37:19 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 4FCB43A6828 for ; Tue, 10 Nov 2009 16:37:19 -0800 (PST) Received: from localhost (host-128-133.meeting.ietf.org [133.93.128.133]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 68D4713D06C4; Wed, 11 Nov 2009 09:37:45 +0900 (JST) Date: Wed, 11 Nov 2009 09:37:47 +0900 (JST) Message-Id: <20091111.093747.145070597.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <947204.74431.qm@web111410.mail.gq1.yahoo.com> References: <947204.74431.qm@web111410.mail.gq1.yahoo.com> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / 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] Presentations X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:37:20 -0000 I prepare my slide soon. Please wait a while. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Mon Nov 16 14:05:50 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851023A6B2B for ; Mon, 16 Nov 2009 14:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku95V5IdFybl for ; Mon, 16 Nov 2009 14:05:49 -0800 (PST) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id D25A43A6B1E for ; Mon, 16 Nov 2009 14:05:49 -0800 (PST) Received: (qmail 15499 invoked by uid 60001); 16 Nov 2009 22:05:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258409149; bh=DrxUkUutYqN2Xsne4q2qehd//HGm0AuD9x7DYowMiTo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nwc9G9L8/5vZX/EG11KBT2WE7Jp9AaBWUTTS+Fulyz3hvDn9dV6w8fsDyVx4Qfc4r8YwInb4q2/QHASgCHlnlIwnWY4vXLierLOcKb0dwXmsy6Pse1PcrUnQutnaRuSPg6AhojCNqbogictzj1BjvzWjwGEx9EHfkecsrFWN8XY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sz4VXg5vCfBYdQEeU9yM68fPajpZKSaePwSFMmT6mw4jVfrCZ6boBNi/HJ9F/rhzqxDH6GAo/52vP2Xjc6njhGDXzvPj9DmSI7JYZ13URM5l1PZ9FSdamFOwwhN+qc1Bk5Nf8uPtqekOYUm2JkmrBTyrQDdHsfdTrZhQi/Fnz6U=; Message-ID: <104789.13616.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: oq7VsIYVM1neARG1iDkyLMIRPSDlVULwqEuLhtdNwpn_LJGuU3CdpD_w3Nu3AVYUWAiPTd9heoJlvxsn2DsUvO4i.M3.D5GcXnM2EtVfFKZCSsuDE.vc..vXMJuHcHwa504krQapPTAchGBd8eN9kn35S_o4HKSs6e6VnYAOuN.pea7tMgB_2PW4jYPFMwbpDD0QEPpZHDE23Ajgfk70HQ4BNkjDc9L0cc8IQNM52gTPEDc39izw_tWI0h8cRkopl1NEFXQLN5WY1vnEUwWOqM1SuUzmnxQcR8s1hsB7PP1vYffs4sH1FpXAsEZgIqqNmeSUFTc4SVGqAzyn5WhZ2HTVNJUe.fQ5rPuk0nMjdW61CWh3GS9cUQ-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Mon, 16 Nov 2009 14:05:49 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Mon, 16 Nov 2009 14:05:49 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:05:50 -0000 Hi all,=0A=A0 Minutes of last week's meeting have been posted at:=0Ahttp://= www.ietf.org/proceedings/09nov/minutes/multimob.txt=0A=0AMany thanks to Dir= k von Hugo and Matthias Waehlisch for taking the minutes so precisely.=0A= =0AAlso thanks to Marshall Eubanks for scribing the Jabber notes at=0Ahttp:= //www.ietf.org/jabber/logs/multimob/2009-11-12.txt=0A=0APlease check the mi= nutes and let us know if any changes are needed.=0A=0ARegards,=0A=0ABehcet= =0A=0A=0A From stig@venaas.com Mon Nov 16 14:32:30 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504B33A67C0 for ; Mon, 16 Nov 2009 14:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OAIqHA-5toH for ; Mon, 16 Nov 2009 14:32:28 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 1002A3A6861 for ; Mon, 16 Nov 2009 14:32:28 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 6E47D21C9C; Mon, 16 Nov 2009 23:32:25 +0100 (CET) Message-ID: <4B01D2F1.9090305@venaas.com> Date: Mon, 16 Nov 2009 14:32:17 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <104789.13616.qm@web111412.mail.gq1.yahoo.com> Content-Type: multipart/mixed; boundary="------------070906000102060903020004" Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:32:30 -0000 This is a multi-part message in MIME format. --------------070906000102060903020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > Hi all, > Minutes of last week's meeting have been posted at: > http://www.ietf.org/proceedings/09nov/minutes/multimob.txt > > Many thanks to Dirk von Hugo and Matthias Waehlisch for taking the minutes so precisely. > > Also thanks to Marshall Eubanks for scribing the Jabber notes at > http://www.ietf.org/jabber/logs/multimob/2009-11-12.txt > > Please check the minutes and let us know if any changes are needed. I think the minutes are a bit too condensed. I think some points may have been missed. Behcet, I propose using the minutes attached to this email. They are in a more verbatim style. Or at least some points in the minutes you posted should be extended. Stig > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --------------070906000102060903020004 Content-Type: text/plain; name="mminbehcet.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mminbehcet.txt" Multicast Mobility WG ====================================== Thursday, November 12 2009, 1300-1500, Room : Cattleya West Behcet: Presented the agenda and the IETF Note-Well. Stig: Clarified the charter. First, we have to work on basic stuff, but keep working on optimization extensions in the background. Jari: Some motivation for the basic stuff: Do it fast and well, then you can work on optimizations. Stig: What do we mean with basics: Multicast support without changes to PMIP and other protocols. IGMP/MLD for Mobility Hitoshi presents his ideas how optimization can take place w/o protocol modification. Stig: Draft interesting, it covers different ways to solve some problems, which are part of the charter. However, charter is fairly strict. Split the draft. Regarding the timers, it is hard to find values that cover all scenarios. Hitoshi: Agree, it is really hard to find specific timer values. Maybe, we can introduce some correlations and describe situations. But it is really hard to define dedicated timer settings. We should clarify this discussion. Thomas Schmidt: The number of retransmits is also important in wireless scenarios. I agree with Stig and Hitoshi: We should define characteristic values with respect to technologies. Suresh Krishnan: I agree. It would also be useful to explain how the modified values affect the protocol operations. Thomas: Slowing down the timers preserve WLAN resources but may affect protocol behaviour (cf. discussions on the mailing list). One has to discuss this part, as well. Hitoshi: I don't want to introduce very, very short intervals to cover mobility, it's harm. Thomas: You cannot assume that MNs use this in the future. Light Weight IGMP/MLD. Jari thinks that profiling (e.g. as would be a pointing to LW protocols) is ok, guidelines should be given ... if this is not possible then state so. Marshall thinks that LW changes protocol - same situation is with unicast general query ... it may take decades for real deployment. (?) Jari: separate things - if LW changes the protocol, we should say so. But that is not task of this WG. Characteristics in wireless environment should be considered where and when affecting the protocol. Thomas: You say there are no cons to use MLD light, but there are advantages to use exclude mode in mobility regimes (cf. discussions on mailing list). Hitoshi: Why a mobile node needs exclude? Stig: In video conferencing for example, you might want to exclude sources to preserve bandwidth, I guess. Unicast MLD Queries. Stig: Unicast MLD Queries might be supported but who has implemented this? I suppose there are no routers that have implemented the query part based on unicast. It would be Interesting to check existing implementations. Stig: Discussed the meaning of tuning IGMP/MLD. My personal opinion is, that it would be fine to support unicast-based MLD Queries if vendors have implemented this. Marshall: Are unicast MLD Qeueries part of the MLD light version? Hitoshi: The MLD light version does not change this aspect. Should we change the name of the draft to consider the described optimizations? Stig: Change the title. We cannot change protocols and nodes (s. charter). Suresh: You have to think about routers, as well. Thomas: A BCP contains advisory. You can add a section what to do if unicast general Query is supported. Stig: It seems that lightweight MLD is orthogonal to mobility scenarios. Jari: There are multiple things: Specify exact timer values, may mean guidance; including the MLD light protocol is profiling. Stig: I am not sure if this could work or not work. Marshall: It seems that lightweight MLD really changes the protocol. Similar to the MLD unicast-based Query, this may introduce problems if there are nodes that do not support this. It takes decades to deploy updated MLD protocol versions. Jari: One have to separate: If MLD light changes protocol, we should state this. Consider wireless specifics when affecting the protocol. Stig: I suggest that Hitoshi separates basic parts of the document. A revised version of the document may be a basis. Additionally, more people should contribute to this MLD draft. Next Steps. No formal adoption of this draft for the charter item yet. It was agreed that the basic part of the draft would be a good basis. More people agreed to contribute. PMIPv6 solution documents. Thomas: Presented "Minimal Deployment Option Solution Overview" Suresh: Presented "PMIPv6 Multicast Support Solution Overview". Marshall: Is there any aggregation? Suresh: No. Seil Jeon: Presented "Mobile Multicasting Support Solution Overview" Stig: Thomas suggested to merge these protocols. Is this your opinion, as well? Seil: Yes. Guang Lu: Presented "Multicast Services Solution Overview". Marshall: Would the multicast LMA be co-located with the unicast LMA? Guang: It doesn't have to be physical boxes, but the functionality is duplicated. Marshall: Does each location of the LMA have to deploy a multicast LMA, or is there a central one? Juan Carlos: No, you can concentrate multicast traffic. Thomas: You would be bound to one LMA. Otherwise severe handover problems may occur. It is not correct to say it solves the scaling problem as you add the avalanche problem to the LMA. Suresh: There can be multiple LMAs, but you need some way to split. Thus, I agree mostly to Thomas. Guang: We do not need one-to-one mapping between unicast and multicast. Thomas: I don't think the picture is right: You cannot split per group, you can only split per MAG. Carlos J. Bernardos: Presented "Multicast Service Delivery Solution Overview" Carlos: I have a question to Thomas' presentation. Your solution requires that each MAG sends an MLD Query. What are the cons in terms of signaling and battery? (2) What will happen if MN is multi-homed (different MAGs), what happens in the case of handover? Thomas: (1) Yes, there is MLD signaling, as well as router signaling (regular PMIP). That's of the same quality (w.r.t. point-to-point links). (2) If the MN is multi-homed, it has several interfaces, which may distribute traffic. That's something the MN has to do. It will get traffic twice, this optimization is out-of-scope and a normal multi-homing 'issue'. Actually, it depends on the interface selection by the MN. It is not really related to mobility. Behcet: Multiple interface selection is out of charter. Carlos: Agree with Thomas' reply, but not to Behcet comment. Stig: There are two options: (1) Context-transfer or (2) MLD Query. Hitoshi: You cannot do context transfer without protocol modifications. Stig: Context transfer is out of the charter. But MLD Query is standard behaviour of MLD routers. Carlos: Can we have multicast traffic between MAG and LMA? Stig: The charter says remote subscription. The question is if basic document leave it optionally. Kent Leung: Are multicast sources within the scope of the charter? Behcet: No. Juan: We have two choices: Avoid convergence on LMA or MAG. Which way we want to go? Should we optimize service continuity? Stig : We got two basic solutions: (1) MLD proxy at MAG (and multicast router if available), (2) Send MLD messages up to the LMA based on tunneling. The states have to be at LMA or MAG. I prefer the MLD proxy solution (personal opinion). Kent: I Agree with Stig, but when you are doing multicast router scheme ... you have states at MAG and LMA. Guang: Direct router solution: It doesn't fit into the charter. (2) Agree with similarities of the solutions. We probably don't have a one fit all solution. Probably, we should evaluate use cases and solutions before we go ahead? Thomas: I agree, the direct routing option is not in the charter. But if there is an operator that has deployed multicast, why not use it? Guang: But it requires to modify the charter. Thomas: Probably not if it is an option. Marshal: When use one or other solution scenarios? Behcet: charter to come to base solution Stig: whatever we decide on, this needs not exclude other solutions completely Behcet: Draft presented does not support IPv4. Thomas: There are no issues with IGMP proxying. Actually, there is a section on IPv4 support within the draft. Stig: All the proposals can easily be extended to IPv4. There is no problem. Behcet: It is not standard behavior that MLD Query is sent out after link change. This is an assumption in the draft presented by Thomas. Stig: I think if a link comes up, a router will send an MLD Query. Thomas: We have talked with Brian Haberman and he confirmed that MLD Query will be sent after link change. Kent: For IGMP it is not standard behaviour that Query is sent when link comes up. Stig: We can conclude: The node would not send report on its own. The question is, how fast the query will be triggered. But that's not a problem. Carlos: There are other approaches that prevent this timer gap problem. Juan: That's what we tried to prevent. Behcet: If we go for the proxy approach, there is the timer gap. Just to highlight this problem. Kent: We need layer two indication. Thomas: This relates to PMIP. It is defined only for point-to-point links. PMIP needs to be aware of link changes. Behcet: We should decide between drafts presented by Suresh and Thomas. Carlos: Are we only decide on this two drafts? Stig: No, no, we decide on the technologies not on the specific drafts. The basic solution relies on one of these two alternatives (MLD proxy or non MLD proxy): Jouni Korhonen: The non MLD proxy solutions have the problem of double encapsulation! Should we consider the techniques described in Krishnan draft? none Should we consider MLD proxy? 16 How many people are uncertain? 2 Behcet: There is a consensus on proxy approaches. Stig: We have decided on a (technical) direction to go, not on a particular draft. Jouni: Why we hurry up? Stig: We have to agree on a solution with respect to milestones. Jari: Basic stuff has to be done to move to the interesting problems. However, we have not to sacrifice anything if solution space needs further investigation. Stig: We continue discussion on the mailing list. Thanks for coming and the good session. --------------070906000102060903020004-- From cjbc@it.uc3m.es Mon Nov 16 14:37:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395C83A6861 for ; Mon, 16 Nov 2009 14:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ2B0FQ29fVY for ; Mon, 16 Nov 2009 14:37:08 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2DE413A685D for ; Mon, 16 Nov 2009 14:37:07 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.209] (82.158.123.77.dyn.user.ono.com [82.158.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id EB3977EF016; Mon, 16 Nov 2009 23:37:04 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <104789.13616.qm@web111412.mail.gq1.yahoo.com> References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Qqi9LGYro+1oH9z93A7q" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 23:37:05 +0100 Message-Id: <1258411025.3443.14.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:37:09 -0000 --=-Qqi9LGYro+1oH9z93A7q Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear chairs, IMHO, there are several interesting discussions that took place during the meeting (e.g., q&a about particular solutions, discussions about the way to move forward, etc) that are not captured in the posted minutes. An approach that I've seen other WGs have followed in the past is to use the recorded audio stream to complete the minutes. I think it would be a good idea that minute takers and/or chairs use the stream to complete the minutes. What do others think? Thanks, Carlos On Mon, 2009-11-16 at 14:05 -0800, Behcet Sarikaya wrote: > Hi all, > Minutes of last week's meeting have been posted at: > http://www.ietf.org/proceedings/09nov/minutes/multimob.txt >=20 > Many thanks to Dirk von Hugo and Matthias Waehlisch for taking the minute= s so precisely. >=20 > Also thanks to Marshall Eubanks for scribing the Jabber notes at > http://www.ietf.org/jabber/logs/multimob/2009-11-12.txt >=20 > Please check the minutes and let us know if any changes are needed. >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Qqi9LGYro+1oH9z93A7q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksB1BEACgkQNdy6TdFwT2cmAwCfaoTk6YOFA2t/05ThqLKPy/NL 7RMAn28ZoEbXncuDxa2hzyGm0yE8WvMd =CxUx -----END PGP SIGNATURE----- --=-Qqi9LGYro+1oH9z93A7q-- From behcetsarikaya@yahoo.com Mon Nov 16 15:12:14 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A373A67B0 for ; Mon, 16 Nov 2009 15:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9waSQHqewMQf for ; Mon, 16 Nov 2009 15:12:14 -0800 (PST) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 46A603A67D7 for ; Mon, 16 Nov 2009 15:12:14 -0800 (PST) Received: (qmail 8771 invoked by uid 60001); 16 Nov 2009 23:12:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258413131; bh=O6TMrqsXOXOmpenw+a7jGUFi/muyWgrBuMTSVFqHCmU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=syLMciSgTDDGvSs76jMH+BeXKzl8TXa0NUW7b01SQvWm8ssd2UBZNGVHVCgMVPMG9b9iclvHR2lrd/5rCg1GkSTxx83qep2vxIdVkrSNosOTiS0YyENLjJfYkOfXPOMm3B2hbAjbV6TnSUPGxcq5b9cWbe28/9/OUVwCW6VRA+8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4748T5aoRbgGitVawpa/0i1WZGYve4gPiXkvy2UCcKm8TMcaCD8nzfyWOC/EanhO4JTyJdMAsBvxy6khIRoIt0bA2QRAr1YSEIolH0nKXgPvDherwdGzg2rHT79XhUExnJYEW5qqZ7fFXVKyI6dk9J/SCeHIcV2XSEMOxK3jX/s=; Message-ID: <126117.8004.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 7dgEwwIVM1ngrzwq1zHE8uLNdcyG2VGPcXPgLLoMv1lbMnIvs4Gm0nYmx6uzBwlIMCPycAfrL.J3WtmsSnmJS_C8UY2T6FviCI_nFO1_QcAcuasNayaQR.f1833cXZPPETMQB.t37D66fpoaAJyEY9XF4A1F0ZrlnQv1Gnt5C9vUPcza6Yj3Xgy.gBdhtpT4wMnY2rPTjhVTwcWkrCY58WUzcSFwD6QH3AGp7PdLpyDpHgNE82OFA4SeT4_Z8IVH7kClLhEwhQBbuzSKUuDLw0CYLfikDJiwDqWVMb9jGN6SXK486tMXGTZDDUeD.h9f9QRPCvW3WU5o9v9fyHQCZtuJwB5HU7pgCjkZZI4n Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 16 Nov 2009 15:12:11 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> Date: Mon, 16 Nov 2009 15:12:11 -0800 (PST) From: Behcet Sarikaya To: cjbc@it.uc3m.es In-Reply-To: <1258411025.3443.14.camel@acorde.it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:12:15 -0000 Hi Carlos,=0A=A0 =0A=0A=0A=0A----- Original Message ----=0A> From: Carlos J= es=FAs Bernardos Cano =0A> To: Behcet Sarikaya =0A> Cc: multimob@ietf.org=0A> Sent: Mon, November 16, 2009 4:37:05= PM=0A> Subject: Re: [multimob] Minutes=0A> =0A> Dear chairs,=0A> =0A> IMHO= , there are several interesting discussions that took place during=0A> the = meeting (e.g., q&a about particular solutions, discussions about the=0A> wa= y to move forward, etc) that are not captured in the posted minutes.=0A> = =0A> An approach that I've seen other WGs have followed in the past is to u= se=0A> the recorded audio stream to complete the minutes.=0A=0AI am not fam= iliar with this being the norm. I have used dime WG style in combining the = two minutes taken by Dirk and Matthias.=0A=0A=0A>=A0I think it would be a= =0A> good idea that minute takers and/or chairs use the stream to complete= =0A> the minutes. =0A=0AIf you wish to volunteer to produce a very detailed= minutes by listening to the audio recording, you are welcome to do so :).= =0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From stig@venaas.com Mon Nov 16 15:22:43 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BEB3A67DA for ; Mon, 16 Nov 2009 15:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAFFtSrK3i6M for ; Mon, 16 Nov 2009 15:22:43 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id B11D93A67A7 for ; Mon, 16 Nov 2009 15:22:42 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id D5EE433B76 for ; Tue, 17 Nov 2009 00:22:40 +0100 (CET) Message-ID: <4B01DEBD.10403@venaas.com> Date: Mon, 16 Nov 2009 15:22:37 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] MLD general query when MN-MAG tunnel comes up X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:22:44 -0000 In the multimob meeting we had some discussion on how quickly a MAG would receive MLD reports from a new MN. My understanding is as follows. 1. MN does not detect movement, hence it will not send reports by itself when moving to a new MAG. 2. When a MN moves to a MAG, a point-to-point tunnel is established, and this will then be a new link. MLDv2 spec (RFC 3810) states: 7.6.2. Querier Election MLDv2 elects a single router per subnet to be in Querier state; all the other routers on the subnet should be in Non-Querier state. MLDv2 uses the same querier election mechanism as MLDv1, namely the IPv6 address. When a router starts operating on a subnet, by default it considers itself as being the Querier. Thus, it sends several General Queries separated by a small time interval (see sections 9.6 and 9.7 for details). [...] and then in 9.6 and 9.7: 9.6. Startup Query Interval The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default value: 1/4 the [Query Interval]. 9.7. Startup Query Count The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default value: [Robustness Variable]. I believe this applies to when link between MN and MAG comes up. So the initial query interval would then with default timers be 125s / 4. Note that this timer can be tuned. What I don't see in this document is anything saying when the first query can be sent. I believe 125s / 4 is too long. When a link comes up, or a router (or proxy in our case) starts up, it makes sense to send the first query as quickly as possible. At least if you look at MLDv1, RFC 2710, you will see a state machine in section 6 starting with: -------------------------------- _______|________ gen. query timer | --------- | | expired | | Initial |---------------->| | (send general query, | --------- (send gen. q., | | start gen. q. timer) | start initial gen. q. | |<---------------------- timer) | Querier | | | -----| |<--- | | | | | |________________| | I read this as immediately sending a general query, and afterwards setting the timer. Also RFC 4541 with considerations for snooping switches say: 4) An IGMP snooping switch should be aware of link layer topology changes caused by Spanning Tree operation. When a port is enabled or disabled by Spanning Tree, a General Query may be sent on all active non-router ports in order to reduce network convergence time. Non-Querier switches should be aware of whether the Querier This is not exactly our scenario, but the idea is the same. I expect implementations to immediately send MLD queries on links coming up. If someone wants, this could be tested with some implementations. Or some of us have access to code we can check. Stig From waehlisch@ieee.org Mon Nov 16 15:24:36 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324523A67E5 for ; Mon, 16 Nov 2009 15:24:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWXF8itx77xd for ; Mon, 16 Nov 2009 15:24:35 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 18DC23A679C for ; Mon, 16 Nov 2009 15:24:35 -0800 (PST) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NAAvw-000AYE-Cr; Tue, 17 Nov 2009 00:24:32 +0100 Date: Tue, 17 Nov 2009 00:24:30 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <126117.8004.qm@web111403.mail.gq1.yahoo.com> Message-ID: References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <126117.8004.qm@web111403.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:24:36 -0000 Hi Behcet, On Mon, 16 Nov 2009, Behcet Sarikaya wrote: > > IMHO, there are several interesting discussions that took place during > > the meeting (e.g., q&a about particular solutions, discussions about the > > way to move forward, etc) that are not captured in the posted minutes. > > > > An approach that I've seen other WGs have followed in the past is to use > > the recorded audio stream to complete the minutes. > > I am not familiar with this being the norm. I have used dime WG style in > combining the two minutes taken by Dirk and Matthias. > I think that your combination of our two minutes has resulted in a very summarized minute overview. I agree with Stig that you should update the posted minutes according to our more detailed notes, or post both the minute overview and a more elaborated merger. Thanks matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From stig@venaas.com Mon Nov 16 15:25:19 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781CA3A6A3E for ; Mon, 16 Nov 2009 15:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VvZ+4LkfTWp for ; Mon, 16 Nov 2009 15:25:18 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 9759F3A6A2A for ; Mon, 16 Nov 2009 15:25:18 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 0BBCD238DC; Tue, 17 Nov 2009 00:25:15 +0100 (CET) Message-ID: <4B01DF58.2040100@venaas.com> Date: Mon, 16 Nov 2009 15:25:12 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> In-Reply-To: <1258411025.3443.14.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:25:19 -0000 Carlos Jesús Bernardos Cano wrote: > Dear chairs, > > IMHO, there are several interesting discussions that took place during > the meeting (e.g., q&a about particular solutions, discussions about the > way to move forward, etc) that are not captured in the posted minutes. > > An approach that I've seen other WGs have followed in the past is to use > the recorded audio stream to complete the minutes. I think it would be a > good idea that minute takers and/or chairs use the stream to complete > the minutes. What do others think? Carlos, do you think the minutes I sent are sufficient? That was based on the raw text by our minute takers and should be fairly close to the audio. Stig > Thanks, > > Carlos > > On Mon, 2009-11-16 at 14:05 -0800, Behcet Sarikaya wrote: >> Hi all, >> Minutes of last week's meeting have been posted at: >> http://www.ietf.org/proceedings/09nov/minutes/multimob.txt >> >> Many thanks to Dirk von Hugo and Matthias Waehlisch for taking the minutes so precisely. >> >> Also thanks to Marshall Eubanks for scribing the Jabber notes at >> http://www.ietf.org/jabber/logs/multimob/2009-11-12.txt >> >> Please check the minutes and let us know if any changes are needed. >> >> 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 cjbc@it.uc3m.es Mon Nov 16 15:31:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9453A6A45 for ; Mon, 16 Nov 2009 15:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7dM8jEqIOGw for ; Mon, 16 Nov 2009 15:31:48 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EC76A3A6A3E for ; Mon, 16 Nov 2009 15:31:47 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.209] (82.158.123.77.dyn.user.ono.com [82.158.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A95373555A8; Tue, 17 Nov 2009 00:31:45 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Stig Venaas In-Reply-To: <4B01DF58.2040100@venaas.com> References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <4B01DF58.2040100@venaas.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ql0iw8f7AMVBaQhi9Wa4" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 00:31:46 +0100 Message-Id: <1258414306.3443.24.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:31:49 -0000 --=-ql0iw8f7AMVBaQhi9Wa4 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Stig, On Mon, 2009-11-16 at 15:25 -0800, Stig Venaas wrote: > Carlos Jes=FAs Bernardos Cano wrote: > > Dear chairs, > >=20 > > IMHO, there are several interesting discussions that took place during > > the meeting (e.g., q&a about particular solutions, discussions about th= e > > way to move forward, etc) that are not captured in the posted minutes. > >=20 > > An approach that I've seen other WGs have followed in the past is to us= e > > the recorded audio stream to complete the minutes. I think it would be = a > > good idea that minute takers and/or chairs use the stream to complete > > the minutes. What do others think? >=20 > Carlos, do you think the minutes I sent are sufficient? That was based > on the raw text by our minute takers and should be fairly close to the > audio. Yes, I think so. These are more complete and should be enough. Thanks! Carlos >=20 > Stig >=20 > > Thanks, > >=20 > > Carlos > >=20 > > On Mon, 2009-11-16 at 14:05 -0800, Behcet Sarikaya wrote: > >> Hi all, > >> Minutes of last week's meeting have been posted at: > >> http://www.ietf.org/proceedings/09nov/minutes/multimob.txt > >> > >> Many thanks to Dirk von Hugo and Matthias Waehlisch for taking the min= utes so precisely. > >> > >> Also thanks to Marshall Eubanks for scribing the Jabber notes at > >> http://www.ietf.org/jabber/logs/multimob/2009-11-12.txt > >> > >> Please check the minutes and let us know if any changes are needed. > >> > >> Regards, > >> > >> Behcet > >> > >> > >> =20 > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www.ietf.org/mailman/listinfo/multimob > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www.ietf.org/mailman/listinfo/multimob >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ql0iw8f7AMVBaQhi9Wa4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksB4OIACgkQNdy6TdFwT2eJWACgvfN1u1AMOrXTMMPGuk4K1XAy xD4AoMzOPj0F/0apG4p3VaNCES8jubE3 =aDL1 -----END PGP SIGNATURE----- --=-ql0iw8f7AMVBaQhi9Wa4-- From cjbc@it.uc3m.es Mon Nov 16 15:34:23 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D38728C1C9 for ; Mon, 16 Nov 2009 15:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcTbKNOcdhHZ for ; Mon, 16 Nov 2009 15:34:22 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 244CA28C1C8 for ; Mon, 16 Nov 2009 15:34:22 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.209] (82.158.123.77.dyn.user.ono.com [82.158.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id ECE523555A8; Tue, 17 Nov 2009 00:34:19 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <126117.8004.qm@web111403.mail.gq1.yahoo.com> References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <126117.8004.qm@web111403.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-nn7Yi9Rwdr7dQLiTp3bq" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 00:34:20 +0100 Message-Id: <1258414460.3443.27.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:34:23 -0000 --=-nn7Yi9Rwdr7dQLiTp3bq Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Mon, 2009-11-16 at 15:12 -0800, Behcet Sarikaya wrote: > Hi Carlos, > =20 >=20 >=20 >=20 > ----- Original Message ---- > > From: Carlos Jes=FAs Bernardos Cano > > To: Behcet Sarikaya > > Cc: multimob@ietf.org > > Sent: Mon, November 16, 2009 4:37:05 PM > > Subject: Re: [multimob] Minutes > >=20 > > Dear chairs, > >=20 > > IMHO, there are several interesting discussions that took place during > > the meeting (e.g., q&a about particular solutions, discussions about th= e > > way to move forward, etc) that are not captured in the posted minutes. > >=20 > > An approach that I've seen other WGs have followed in the past is to us= e > > the recorded audio stream to complete the minutes. >=20 > I am not familiar with this being the norm. I have used dime WG style in = combining the two minutes taken by Dirk and Matthias. Well, it is not the norm, but it has been used in the past (e.g., AUTOCONF, IETF 75th) when the initial minutes were not considered complete enough. >=20 >=20 > > I think it would be a > > good idea that minute takers and/or chairs use the stream to complete > > the minutes.=20 >=20 > If you wish to volunteer to produce a very detailed minutes by listening = to the audio recording, you are welcome to do so :). I think that I'd kindly decline your invitation this time :), especially because the minutes provided by Stig are good enough, IMHO. Thanks, Carlos >=20 >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-nn7Yi9Rwdr7dQLiTp3bq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksB4XwACgkQNdy6TdFwT2fV4QCggvW0R7IhVk9jEZu8yFu2f18e l2gAn1FV0ia7Bq3jVVtP/q12Z9T5TmCn =e/eN -----END PGP SIGNATURE----- --=-nn7Yi9Rwdr7dQLiTp3bq-- From behcetsarikaya@yahoo.com Mon Nov 16 15:42:31 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168FA3A6A15 for ; Mon, 16 Nov 2009 15:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfFSBhwv8ATt for ; Mon, 16 Nov 2009 15:42:30 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 5DE943A679C for ; Mon, 16 Nov 2009 15:42:29 -0800 (PST) Received: (qmail 46016 invoked by uid 60001); 16 Nov 2009 23:42:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258414945; bh=84/KayU3Ug8S4nJLE0O4JqgL1rDh+erZre0WQplA8ww=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CKJPrGiCmjrqPwKafqg7bGb2dntoQGPJPpNmzXYWBugqeCn5ekfdMc6bmUIzXOoCsODTXJpa2bVI1HihZjNSUdlu6f9VGBB205PA9AL4Hz+j3DDSeBKspI9RotK+UHa6jnwVZwNHdtSIQRWGCTbSdQKoJPfol9qAv5ZBTUfTGwE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Oix9N82tgbepznEVFyJGFq3gpnY4kRLoOrBpeNyLoJ+p30ciX4VEpXWk+qBlVmi/Zh4VkipoFUVUcrJNTwOhBOr2LNi8lfLOq7JnbQJSLQqsNg600rqtF7jmriT753OsrFyGfvsq/ECoLbAM2r0cBAwZJ6sNVBOvkJvZdSxjaxg=; Message-ID: <973875.45760.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: knRIceMVM1n516q.9twi77lS45z.N5rCjF1HbgeYsHuC4kqo97R2Y23kmF3OeDcmzerkpLdK1f9hzh28N1MR_WdLePECWrxgX828ZkrJxERrtYDo6KvTLi7.o1omQXO2PhnbprZ1IghYiZ7yOWBJaqQe7mWPhwi4irzrQWyhANuuV8U5r1mWZZWZJCckXh2akyudOWUoiZ5NoHCd5gO9mbqcYvPVmwA6T0vIq0SyeBwaSU0AtiUulyx7odilS9.nVKX6.GLBpW6kbDaJIhxJUahU6HTExScWmk1tRT1mnA57mKPoobgJJMfUlBeXOc8mbYsBiKJmD2QBz23Bx.sYSdwit9h2rrsEJ56brh0yoATyDw-- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 16 Nov 2009 15:42:25 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <126117.8004.qm@web111403.mail.gq1.yahoo.com> Date: Mon, 16 Nov 2009 15:42:25 -0800 (PST) From: Behcet Sarikaya To: Matthias Waehlisch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:42:31 -0000 Hi Matthias, all,=0A=A0 Yes, I added original versions of the two minutes a= nd posted the resulting text at:=0Ahttp://www.ietf.org/proceedings/09nov/mi= nutes/multimob.txt=0A=0A=0A=0AHave fun :).=0A=0ARegards,=0A=0ABehcet=0A=0A-= ---- Original Message ----=0A> From: Matthias Waehlisch =0A> To: Behcet Sarikaya =0A> Cc: cjbc@it.uc3m.es; mult= imob@ietf.org=0A> Sent: Mon, November 16, 2009 5:24:30 PM=0A> Subject: Re: = [multimob] Minutes=0A> =0A> Hi Behcet,=0A> =0A> On Mon, 16 Nov 2009, Behcet= Sarikaya wrote:=0A> =0A> > > IMHO, there are several interesting discussio= ns that took place during=0A> > > the meeting (e.g., q&a about particular s= olutions, discussions about the=0A> > > way to move forward, etc) that are = not captured in the posted minutes.=0A> > > =0A> > > An approach that I've = seen other WGs have followed in the past is to use=0A> > > the recorded aud= io stream to complete the minutes.=0A> > =0A> > I am not familiar with this= being the norm. I have used dime WG style in =0A> > combining the two minu= tes taken by Dirk and Matthias.=0A> > =0A> =A0 I think that your combinatio= n of our two minutes has resulted in a very =0A> summarized minute overview= . I agree with Stig that you should update the =0A> posted minutes accordin= g to our more detailed notes, or post both the =0A> minute overview and a m= ore elaborated merger.=0A> =0A> =0A> Thanks=0A> =A0 matthias=0A> =0A> -- = =0A> Matthias Waehlisch=0A> .=A0 FU Berlin, Inst. fuer Informatik, AG CST= =0A> .=A0 Takustr. 9, D-14195 Berlin, Germany=0A> .. mailto:waehlisch@ieee.= org .. http://www.inf.fu-berlin.de/~waehl=0A> :. Also: http://inet.cpt.haw-= hamburg.de .. http://www.link-lab.net=0A=0A=0A=0A From behcetsarikaya@yahoo.com Mon Nov 16 15:46:20 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F853A6B45 for ; Mon, 16 Nov 2009 15:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=1.443, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2nrtoCDy2nZ for ; Mon, 16 Nov 2009 15:46:20 -0800 (PST) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id 2B5583A679C for ; Mon, 16 Nov 2009 15:46:20 -0800 (PST) Received: (qmail 67506 invoked by uid 60001); 16 Nov 2009 23:46:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258415179; bh=8SiKVF7CLgOsHPCLnTKmrXZlXEgpcK1mL/2V3KPIPyU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oEIUaW+vyNfw0Hioc3z8tjvjay1pp7QYy6McOk0otLlnAp08VlnzIQtCdcra9Wf7i6OGjMrRg9hhgjsnXUGHPRvg6joDns8SrLuX+5r3RPzpMNUNaIU+uDZMPQsigB6GckIjMnVvfriuwY0hGN5cza+vk8FMuK5rL7y5Q2cISrA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lA9MEN7K0rJEphV5PPj0mSrUi0XLO5gNOpQVV4Fm8SBVP7wmPe6gYC4Hh6qUIQ3KembXQhv5PmfvpTP4WUgGttwSnZKtZufF9a9psucHLyyptYppBBXpBZ0eSRXvqk1FssVzN3UkTG/wjtPyc5P7JIN0J42qVAGGiEv4NlU3l9U=; Message-ID: <413211.67469.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: 07TjTUgVM1nqPnzPgH9kanj0OsR_Jf14CkuWbcW_gflwY3DCH2mG7gulTbLVCQEfHUE1aHZrEQlw38gf14WZg2NW36rmjqCLO.sfdmnr9mYwknGpeyCiGRLR3FWjg3yl1rtKpuCAoGMblMOrZALxQdhYsRJ5Qm7gCWELNlN4vJMdAZfdbYLWz1OXO0FrNwaYd4DazYKcats.1r5Sv268yI1fMN5EuL59wmRcepB56BliN9DYulBcZNHcOTsKhs35Ksr7GoaAfKNqB7.RSSNrkBShoR39K3b3GPTnrlB8kadDHDS.0ftQ9Gon2WlWQ37.jv2.iKSRHULYd3lXi3Ul0rdSi1ZLJXBc1YOuLB7a Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Mon, 16 Nov 2009 15:46:19 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <126117.8004.qm@web111403.mail.gq1.yahoo.com> <1258414460.3443.27.camel@acorde.it.uc3m.es> Date: Mon, 16 Nov 2009 15:46:19 -0800 (PST) From: Behcet Sarikaya To: cjbc@it.uc3m.es In-Reply-To: <1258414460.3443.27.camel@acorde.it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:46:21 -0000 Hi Carlos,=0A=A0 Normal procedure is WG members provide text to add/replace= parts of the posted minutes (which of course may be questioned by other pe= ople).=0A=A0 =0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----= =0A> From: Carlos Jes=FAs Bernardos Cano =0A> To: Behcet S= arikaya =0A> Cc: multimob@ietf.org=0A> Sent: Mon, Novemb= er 16, 2009 5:34:20 PM=0A> Subject: Re: [multimob] Minutes=0A> =0A> Hi Behc= et,=0A> =0A> On Mon, 2009-11-16 at 15:12 -0800, Behcet Sarikaya wrote:=0A> = > Hi Carlos,=0A> >=A0 =0A> > =0A> > =0A> > =0A> > ----- Original Message --= --=0A> > > From: Carlos Jes=FAs Bernardos Cano =0A> > > To: Behcet Sarikaya= =0A> > > Cc: multimob@ietf.org=0A> > > Sent: Mon, November 16, 2009 4:37:0= 5 PM=0A> > > Subject: Re: [multimob] Minutes=0A> > > =0A> > > Dear chairs,= =0A> > > =0A> > > IMHO, there are several interesting discussions that took= place during=0A> > > the meeting (e.g., q&a about particular solutions, di= scussions about the=0A> > > way to move forward, etc) that are not captured= in the posted minutes.=0A> > > =0A> > > An approach that I've seen other W= Gs have followed in the past is to use=0A> > > the recorded audio stream to= complete the minutes.=0A> > =0A> > I am not familiar with this being the n= orm. I have used dime WG style in =0A> combining the two minutes taken by D= irk and Matthias.=0A> =0A> Well, it is not the norm, but it has been used i= n the past (e.g.,=0A> AUTOCONF, IETF 75th) when the initial minutes were no= t considered=0A> complete enough.=0A> =0A> > =0A> > =0A> > > I think it wou= ld be a=0A> > > good idea that minute takers and/or chairs use the stream t= o complete=0A> > > the minutes. =0A> > =0A> > If you wish to volunteer to p= roduce a very detailed minutes by listening to =0A> the audio recording, yo= u are welcome to do so :).=0A> =0A> I think that I'd kindly decline your in= vitation this time :), especially=0A> because the minutes provided by Stig = are good enough, IMHO.=0A> =0A> Thanks,=0A> =0A> Carlos=0A> =0A> > =0A> > = =0A> > Regards,=0A> > =0A> > Behcet=0A> > =0A> > =0A> >=A0 =A0 =A0 =0A> -- = =0A> Carlos Jes=FAs Bernardos Cano=A0 =A0 http://www.netcoms.net=0A> GPG FP= : D29B 0A6A 639A A561 93CA=A0 4D55 35DC BA4D D170 4F67=0A=0A=0A=0A From cjbc@it.uc3m.es Mon Nov 16 15:52:14 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5F13A6B47 for ; Mon, 16 Nov 2009 15:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.032 X-Spam-Level: X-Spam-Status: No, score=-7.032 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP9L1MvHzzDs for ; Mon, 16 Nov 2009 15:52:13 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 00ADB3A6B49 for ; Mon, 16 Nov 2009 15:52:12 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.209] (82.158.123.77.dyn.user.ono.com [82.158.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A5F297EF03C; Tue, 17 Nov 2009 00:52:10 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <413211.67469.qm@web111412.mail.gq1.yahoo.com> References: <104789.13616.qm@web111412.mail.gq1.yahoo.com> <1258411025.3443.14.camel@acorde.it.uc3m.es> <126117.8004.qm@web111403.mail.gq1.yahoo.com> <1258414460.3443.27.camel@acorde.it.uc3m.es> <413211.67469.qm@web111412.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MqQD2EoLoWeQaGAwKZHC" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 00:52:10 +0100 Message-Id: <1258415530.3443.31.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 23:52:14 -0000 --=-MqQD2EoLoWeQaGAwKZHC Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Mon, 2009-11-16 at 15:46 -0800, Behcet Sarikaya wrote: > Hi Carlos, > Normal procedure is WG members provide text to add/replace parts of the= posted minutes (which of course may be questioned by other people). Fully agree. My proposal was to use the recorded audio stream to help WG members add/replace parts of the posted minutes, which is fully inline with your view, I guess. Basically, my point was that if we need to complete something from the minutes (that was my opinion considering the first version of the posted minutes), the audio stream may be a very valuable resource. Thanks, Carlos P.S. I guess this is enough discussion about procedures. Lets focus on multimob issues :-D > =20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Original Message ---- > > From: Carlos Jes=FAs Bernardos Cano > > To: Behcet Sarikaya > > Cc: multimob@ietf.org > > Sent: Mon, November 16, 2009 5:34:20 PM > > Subject: Re: [multimob] Minutes > >=20 > > Hi Behcet, > >=20 > > On Mon, 2009-11-16 at 15:12 -0800, Behcet Sarikaya wrote: > > > Hi Carlos, > > > =20 > > >=20 > > >=20 > > >=20 > > > ----- Original Message ---- > > > > From: Carlos Jes=FAs Bernardos Cano=20 > > > > To: Behcet Sarikaya=20 > > > > Cc: multimob@ietf.org > > > > Sent: Mon, November 16, 2009 4:37:05 PM > > > > Subject: Re: [multimob] Minutes > > > >=20 > > > > Dear chairs, > > > >=20 > > > > IMHO, there are several interesting discussions that took place dur= ing > > > > the meeting (e.g., q&a about particular solutions, discussions abou= t the > > > > way to move forward, etc) that are not captured in the posted minut= es. > > > >=20 > > > > An approach that I've seen other WGs have followed in the past is t= o use > > > > the recorded audio stream to complete the minutes. > > >=20 > > > I am not familiar with this being the norm. I have used dime WG style= in=20 > > combining the two minutes taken by Dirk and Matthias. > >=20 > > Well, it is not the norm, but it has been used in the past (e.g., > > AUTOCONF, IETF 75th) when the initial minutes were not considered > > complete enough. > >=20 > > >=20 > > >=20 > > > > I think it would be a > > > > good idea that minute takers and/or chairs use the stream to comple= te > > > > the minutes.=20 > > >=20 > > > If you wish to volunteer to produce a very detailed minutes by listen= ing to=20 > > the audio recording, you are welcome to do so :). > >=20 > > I think that I'd kindly decline your invitation this time :), especiall= y > > because the minutes provided by Stig are good enough, IMHO. > >=20 > > Thanks, > >=20 > > Carlos > >=20 > > >=20 > > >=20 > > > Regards, > > >=20 > > > Behcet > > >=20 > > >=20 > > > =20 > > --=20 > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >=20 >=20 >=20 > =20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-MqQD2EoLoWeQaGAwKZHC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksB5aoACgkQNdy6TdFwT2fNtwCcD/GMqdUfoEOqTJU7pk4fMAtw GHsAoLYTqlBwM9cKRwgyEgaDDXanH0qS =/uvA -----END PGP SIGNATURE----- --=-MqQD2EoLoWeQaGAwKZHC-- From behcetsarikaya@yahoo.com Thu Nov 19 09:13:27 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DA528C0D6 for ; Thu, 19 Nov 2009 09:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq6kbbwbBVHi for ; Thu, 19 Nov 2009 09:13:26 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id D93E13A6964 for ; Thu, 19 Nov 2009 09:13:26 -0800 (PST) Received: (qmail 32587 invoked by uid 60001); 19 Nov 2009 17:13:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258650804; bh=1fn0dl0cJF3KfjIlbDVt9y40LySADNnbVY8hJqKzjko=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=thXtaU2/ybtnHuMhfjxgnqyZpDOQIx9eYTeEmbKnSyqKtNt/9X7Arys6bXLw6WvfiJoI/JXja6B4xm69kQfMysYZhA21q1qtOfvct/n92m5LHO9A6RMMRzuKjXps2+KkDTqMot/K6uJRVttp5FGRchoLcjgIK+wHeZAfJ22Xwjo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1My5eKoOknlbHwbhSjnTzeT2QOtYe6JRE4jLMRAiLYOa+P8UglCyN/ndhy0jl7NPqVAxiuKASZi7eq5DbQVz97X5Kgj5BasJNTaKEh7Yvva1EcajZ+HzFnZhXZscfZSuc6V2axISZnmheU9fTLoBT6C2GpAGJ3mnozkmoGtzoqQ=; Message-ID: <917218.31788.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: UqHxOM4VM1mhCbOQd0FOHnLOVpBi4jWW.gl_Lky2SvPrq5V7XxvoJqeAd8YFLatUj.nlMFoemvgqwaFNayjQ4YXlHf0.dYhb40wjaIzjvIFD9S7PO06abJ.1nfm2M4ZsTmEg1pW..s7bhZZC626jLK_q_kCXVCiJIdSY7s_m_p.hSqGRI3Ra7yLtKLELuEAVdWC6QdOaKMQn2etOHTvZ0dAi_IXel83u.0O9ST.wWMNsCPlwt4kFkiGb8jTHtV35YzWpYMRVxaLrwscKOBUqIxJBnNIea8v_DNAvNzDqMNLhjCK8smo6JH1I7GOtGP3LHSD7BoU_i_KZkrLfvISE5vE- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Thu, 19 Nov 2009 09:13:24 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 Date: Thu, 19 Nov 2009 09:13:24 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:13:27 -0000 Hello Folks,=0A=A0 Stig and I have been debating this issue, maybe it is ti= me to talk about this now: There is an opinion that =0A=0AIGMP/MLD Proxy at= the MAG is not in the current charter=0A=0Adue to=0A=0A1. Charter requires= remote subscription technique and IGMP/MLD Proxy is not exactly remote sub= scription,=0A=0A2. Charter says optimizations to deal with avalanche proble= m will be dealt with after rechartering (the last clause in the charter).= =0AIGMP/MLD Proxy solves avalanche problem.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A From schmidt@informatik.haw-hamburg.de Thu Nov 19 09:24:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DA43A6882 for ; Thu, 19 Nov 2009 09:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRTRQozyVWIe for ; Thu, 19 Nov 2009 09:24:48 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id DED703A6849 for ; Thu, 19 Nov 2009 09:24:47 -0800 (PST) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NBAkM-000HUM-5n; Thu, 19 Nov 2009 18:24:43 +0100 Message-ID: <4B057F52.8010208@informatik.haw-hamburg.de> Date: Thu, 19 Nov 2009 18:24:34 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <917218.31788.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:24:49 -0000 Hi Behcet, from my perspective, there are two answers to this: 1. The sense of the charter is to produce (good) solutions without protocol modifications. If the wording of the charter is misleading, we have to follow its sense ... as Jari said: there are no holy words in the charter, Multimob should attempt to do serious, good work fast! 2. IMHO, there is no issue with charter words: - the term "Remote Subscription" as defined in the literature (-> see problem statement) was coined as counterpart to "home subscription" (HA-Tunneling). All the approaches we have been discussing in Hiroshima are of type "remote subscription". - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel convergence problems in full. But even if it did (without protocol modification), that would be fine and in no contradiction with the charter - as the charter just singles out optimizations that do change protocols. In conclusion: you should not debate this artifact. It is a pure waste of time and drives the group away from serious work and momentum to solutions. Cheers Thomas Behcet Sarikaya wrote: > Hello Folks, > Stig and I have been debating this issue, maybe it is time to talk about this now: There is an opinion that > > IGMP/MLD Proxy at the MAG is not in the current charter > > due to > > 1. Charter requires remote subscription technique and IGMP/MLD Proxy is not exactly remote subscription, > > 2. Charter says optimizations to deal with avalanche problem will be dealt with after rechartering (the last clause in the charter). > IGMP/MLD Proxy solves avalanche problem. > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jouni.nospam@gmail.com Thu Nov 19 15:31:59 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50273A6810 for ; Thu, 19 Nov 2009 15:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs12Y39I1kxe for ; Thu, 19 Nov 2009 15:31:59 -0800 (PST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id E02403A67E4 for ; Thu, 19 Nov 2009 15:31:58 -0800 (PST) Received: from a88-114-70-12.elisa-laajakaista.fi (a88-114-70-12.elisa-laajakaista.fi [88.114.70.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id AB4262165DB; Fri, 20 Nov 2009 01:31:52 +0200 (EET) References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <917218.31788.qm@web111406.mail.gq1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> Content-Transfer-Encoding: 7bit From: jouni Date: Fri, 20 Nov 2009 01:31:52 +0200 To: Behcet Sarikaya X-Mailer: Apple Mail (2.1076) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:31:59 -0000 Hi Behcet, On Nov 19, 2009, at 7:13 PM, Behcet Sarikaya wrote: > Hello Folks, > Stig and I have been debating this issue, maybe it is time to talk > about this now: There is an opinion that > > IGMP/MLD Proxy at the MAG is not in the current charter > > due to > > 1. Charter requires remote subscription technique and IGMP/MLD Proxy > is not exactly remote subscription, From the current charter: > Specific goals for the group are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment The above does not prevent us working on a MLD Proxy based solution or any other solution. And if the solution, be that MLD Proxy or something else, works also in a mode where all data comes through LMA, the remote subscription requirement is also met. > > 2. Charter says optimizations to deal with avalanche problem will be > dealt with after rechartering (the last clause in the charter). > IGMP/MLD Proxy solves avalanche problem. I am confused. What this has to do with optimizations? As far as I understand it now, MLD Proxy seems to address the following charter requirements: "This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host." This can of course change if we get/find new facts that state opposite. Cheers, Jouni > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From cjbc@it.uc3m.es Thu Nov 19 15:55:05 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD05C3A69C0 for ; Thu, 19 Nov 2009 15:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giO0KQ1bdX54 for ; Thu, 19 Nov 2009 15:55:04 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6DEA83A680F for ; Thu, 19 Nov 2009 15:55:04 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.209] (82.159.18.17.dyn.user.ono.com [82.159.18.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 39AA3BA83BD; Fri, 20 Nov 2009 00:55:00 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" In-Reply-To: <4B057F52.8010208@informatik.haw-hamburg.de> References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <4B057F52.8010208@informatik.haw-hamburg.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ha7BtjXa2uemZB7s6eP4" Organization: Universidad Carlos III de Madrid Date: Fri, 20 Nov 2009 00:55:01 +0100 Message-Id: <1258674901.4074.57.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:55:05 -0000 --=-ha7BtjXa2uemZB7s6eP4 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Agree. Carlos On Thu, 2009-11-19 at 18:24 +0100, Thomas C. Schmidt wrote: > Hi Behcet, >=20 > from my perspective, there are two answers to this: >=20 > 1. The sense of the charter is to produce (good) solutions without=20 > protocol modifications. If the wording of the charter is misleading, we=20 > have to follow its sense ... as Jari said: there are no holy words in=20 > the charter, Multimob should attempt to do serious, good work fast! >=20 > 2. IMHO, there is no issue with charter words: > - the term "Remote Subscription" as defined in the literature (->=20 > see problem statement) > was coined as counterpart to "home subscription" (HA-Tunneling).=20 > All the approaches we > have been discussing in Hiroshima are of type "remote subscription= ". > - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel=20 > convergence problems in full. > But even if it did (without protocol modification), that would be=20 > fine and in no > contradiction with the charter - as the charter just singles out=20 > optimizations that do > change protocols. >=20 > In conclusion: you should not debate this artifact. It is a pure waste=20 > of time and drives the group away from serious work and momentum to=20 > solutions. >=20 > Cheers >=20 > Thomas >=20 > Behcet Sarikaya wrote: > > Hello Folks, > > Stig and I have been debating this issue, maybe it is time to talk ab= out this now: There is an opinion that=20 > >=20 > > IGMP/MLD Proxy at the MAG is not in the current charter > >=20 > > due to > >=20 > > 1. Charter requires remote subscription technique and IGMP/MLD Proxy is= not exactly remote subscription, > >=20 > > 2. Charter says optimizations to deal with avalanche problem will be de= alt with after rechartering (the last clause in the charter). > > IGMP/MLD Proxy solves avalanche problem. > >=20 > > Regards, > >=20 > > Behcet > >=20 > >=20 > > =20 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ha7BtjXa2uemZB7s6eP4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksF2tQACgkQNdy6TdFwT2etVACglrY2ABN5cpxKvGi7LpWty/Cv w1gAn20V4iOo8p30vCgxSWpztxVBvHrn =GPDe -----END PGP SIGNATURE----- --=-ha7BtjXa2uemZB7s6eP4-- From Guang.Lu@InterDigital.com Fri Nov 20 08:14:05 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0593A6969 for ; Fri, 20 Nov 2009 08:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv6inp1u4Kd6 for ; Fri, 20 Nov 2009 08:14:04 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 9247C3A67A6 for ; Fri, 20 Nov 2009 08:14:04 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 11:14:01 -0500 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 11:13:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Nov 2009 11:13:42 -0500 Message-ID: In-reply-to: <1258674901.4074.57.camel@acorde.it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] IGMP/MLD Proxy at the MAG Thread-Index: Acppc7l5lE7kOTlSQAGFMKqkDCDW/AAh/W5A References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><4B057F52.8010208@informatik.haw-hamburg.de> <1258674901.4074.57.camel@acorde.it.uc3m.es> From: "Lu, Guang" To: X-OriginalArrivalTime: 20 Nov 2009 16:13:41.0844 (UTC) FILETIME=[6D367140:01CA69FC] Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:14:05 -0000 We also agree with the reasoning by Thomas and Jouni.=20 Best regards, Guang & Juan Carlos > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Carlos Jes=FAs Bernardos Cano > Sent: Thursday, November 19, 2009 6:55 PM > To: Thomas C. Schmidt > Cc: multimob@ietf.org > Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >=20 > Agree. >=20 > Carlos >=20 > On Thu, 2009-11-19 at 18:24 +0100, Thomas C. Schmidt wrote: > > Hi Behcet, > > > > from my perspective, there are two answers to this: > > > > 1. The sense of the charter is to produce (good) solutions without > > protocol modifications. If the wording of the charter is misleading, > > we have to follow its sense ... as Jari said: there are no holy = words > > in the charter, Multimob should attempt to do serious, good work > fast! > > > > 2. IMHO, there is no issue with charter words: > > - the term "Remote Subscription" as defined in the literature = (- > > > > see problem statement) > > was coined as counterpart to "home subscription" (HA- > Tunneling). > > All the approaches we > > have been discussing in Hiroshima are of type "remote > subscription". > > - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel > > convergence problems in full. > > But even if it did (without protocol modification), that = would > > be fine and in no > > contradiction with the charter - as the charter just singles > > out optimizations that do > > change protocols. > > > > In conclusion: you should not debate this artifact. It is a pure > waste > > of time and drives the group away from serious work and momentum to > > solutions. > > > > Cheers > > > > Thomas > > > > Behcet Sarikaya wrote: > > > Hello Folks, > > > Stig and I have been debating this issue, maybe it is time to > talk > > > about this now: There is an opinion that > > > > > > IGMP/MLD Proxy at the MAG is not in the current charter > > > > > > due to > > > > > > 1. Charter requires remote subscription technique and IGMP/MLD > Proxy > > > is not exactly remote subscription, > > > > > > 2. Charter says optimizations to deal with avalanche problem will > be dealt with after rechartering (the last clause in the charter). > > > IGMP/MLD Proxy solves avalanche problem. > > > > > > Regards, > > > > > > Behcet > > > > > > > > > > > > _______________________________________________ > > > multimob mailing list > > > multimob@ietf.org > > > https://www.ietf.org/mailman/listinfo/multimob > > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From behcetsarikaya@yahoo.com Fri Nov 20 09:09:19 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5D73A6946 for ; Fri, 20 Nov 2009 09:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cqzTShJtttE for ; Fri, 20 Nov 2009 09:09:18 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 120093A689E for ; Fri, 20 Nov 2009 09:09:18 -0800 (PST) Received: (qmail 5098 invoked by uid 60001); 20 Nov 2009 17:09:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258736953; bh=jS735pAGmVA7XwgSL7WiBsSVLpGCrcYbPCUPmc8a5N8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kUDhBA5XvPuFzwxNUdC6NnjcqCmFjv5X2YuVGx2b3i42cYd+i87K8tlizC94hODXW3m6I2p7GUp4r1aaqnHwmaw+ifBP/T+FO/lFygw0gzfDFnAyqHb1VagT/zrUAOjr2rT8tHYxdF04ZhxjmzypA7y1N+cDY2uuRN6BjnGANr4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JzjBUhgmJRBfkT/wNr3EN57C+8WGHTmuDrf+W79licKCesSdDzD8PjzAoU/WEpmL9ypjCbl4frgJZk05vuy/316hkAUw3nlK6h8cz/m0bfnxCqJlr5bWAOxU2tQKjAA0xrOGXbaS6GbzI47aGd6rRNghl1ScqIgxe9uMEDExC6E=; Message-ID: <28852.3922.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: fg4sLcEVM1laleV_k8AuStJlb7R.pcgTWP2F_i84e27yfakffa0jbynUXGMrOuHz9g.SW1Fhm1HZSUdaCqG63EJSyUrJPGEm1EL3mTIdbQ8YfwBJ5e0rOC8AcI7iveGlVvmAdg07nl4bWsUQqE068mhCIgMXTAUV_mADBVJ0UqK7c2xHGwD9ewdndLkKvWM8xb6.LvwzlplhVdqbYs9BS9J4yeuAqdT1fie.y77ftoFnmunSmXLLY9RKvUkOdqyskykdCccd74MooFT35ne.AhBk.yX9Y1WjcVd6GpmV7y5jkRzEIj5DFqlINEiLkh5FolcbtofxScSNk8AtQ5DaCCpMZIUHHJ7dHSOUge.W Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Fri, 20 Nov 2009 09:09:12 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <4B057F52.8010208@informatik.haw-hamburg.de> Date: Fri, 20 Nov 2009 09:09:12 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4B057F52.8010208@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:09:19 -0000 Hi Thomas,=0A=0A=A0 Remote subscription together with dealing with avalanch= e problem after rechartering means remote subscription and bi-directional t= unneling as described in draft-irtf-mobopts-mmcastv6-ps-09.txt.=0A=0A=A0 It= is true that the charter did not spell out bi-directional tunneling, but i= t is implied, I don't think the charter needed to do this, right? It was ou= t for review by public, we received no comments for further clarification.= =0A=0A=A0 Thomas, I think it is clear that IGMP/MLD Proxy=A0or MR at the MA= G approaches do solve the avalanche problem.=0A=0A=A0 Tunnel convergence is= not well defined, in our chairs' evaluation we defined it as the problem o= f multiple LMAs sending duplicate multicast data to IGMP/MLD Proxy. I think= it is better to stick to this definition and separate the avalanche from t= unnel convergence. MR at the MAG does solve both avalanche and tunnel conve= rgence problems.=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Mes= sage ----=0A> From: Thomas C. Schmidt = =0A> To: Behcet Sarikaya =0A> Cc: multimob@ietf.org=0A> = Sent: Thu, November 19, 2009 11:24:34 AM=0A> Subject: Re: [multimob] IGMP/M= LD Proxy at the MAG=0A> =0A> Hi Behcet,=0A> =0A> from my perspective, there= are two answers to this:=0A> =0A> 1. The sense of the charter is to produc= e (good) solutions without protocol =0A> modifications. If the wording of t= he charter is misleading, we have to follow =0A> its sense ... as Jari said= : there are no holy words in the charter, Multimob =0A> should attempt to d= o serious, good work fast!=0A> =0A> 2. IMHO, there is no issue with charter= words:=0A> =A0 =A0 - the term "Remote Subscription" as defined in the lite= rature (-> see =0A> problem statement)=0A> =A0 =A0 =A0 was coined as counte= rpart to "home subscription" (HA-Tunneling). All the =0A> approaches we=0A>= =A0 =A0 =A0 have been discussing in Hiroshima are of type "remote subscrip= tion".=0A> =A0 =A0 - IGMP/MLD Proxy at the MAG does not solve avalanche/tun= nel convergence =0A> problems in full.=0A> =A0 =A0 =A0 But even if it did (= without protocol modification), that would be fine and =0A> in no=0A> =A0 = =A0 =A0 contradiction with the charter - as the charter just singles out = =0A> optimizations that do=0A> =A0 =A0 =A0 change protocols.=0A> =0A> In co= nclusion: you should not debate this artifact. It is a pure waste of time = =0A> and drives the group away from serious work and momentum to solutions.= =0A> =0A> Cheers=0A> =0A> Thomas=0A> =0A> Behcet Sarikaya wrote:=0A> > Hell= o Folks,=0A> >=A0 Stig and I have been debating this issue, maybe it is tim= e to talk about this =0A> now: There is an opinion that =0A> > IGMP/MLD Pro= xy at the MAG is not in the current charter=0A> > =0A> > due to=0A> > =0A> = > 1. Charter requires remote subscription technique and IGMP/MLD Proxy is n= ot =0A> exactly remote subscription,=0A> > =0A> > 2. Charter says optimizat= ions to deal with avalanche problem will be dealt =0A> with after recharter= ing (the last clause in the charter).=0A> > IGMP/MLD Proxy solves avalanche= problem.=0A> > =0A> > Regards,=0A> > =0A> > Behcet=0A> > =0A> > =0A> >=A0 = =A0 =A0 _______________________________________________=0A> > multimob mail= ing list=0A> > multimob@ietf.org=0A> > https://www.ietf.org/mailman/listinf= o/multimob=0A> =0A> -- =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0 Hamburg Uni= versity of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berliner Tor= 7 =B0=0A> =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 H= amburg, Germany =B0=0A> =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42875-8452 =B0=0A> =B0 http://www.informati= k.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =B0=0A=0A=0A=0A = From stig@venaas.com Fri Nov 20 12:58:28 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1E63A688B for ; Fri, 20 Nov 2009 12:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gK6MPfA+ZLi for ; Fri, 20 Nov 2009 12:58:27 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id B799C3A67AF for ; Fri, 20 Nov 2009 12:58:26 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 910DF33B7D; Fri, 20 Nov 2009 21:58:22 +0100 (CET) Message-ID: <4B0702EB.3090502@venaas.com> Date: Fri, 20 Nov 2009 12:58:19 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <4B057F52.8010208@informatik.haw-hamburg.de> <28852.3922.qm@web111405.mail.gq1.yahoo.com> In-Reply-To: <28852.3922.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:58:28 -0000 Behcet Sarikaya wrote: > Hi Thomas, > > Remote subscription together with dealing with avalanche problem after rechartering means remote subscription and bi-directional tunneling as described in draft-irtf-mobopts-mmcastv6-ps-09.txt. > > It is true that the charter did not spell out bi-directional tunneling, but it is implied, I don't think the charter needed to do this, right? It was out for review by public, we received no comments for further clarification. > > Thomas, I think it is clear that IGMP/MLD Proxy or MR at the MAG approaches do solve the avalanche problem. > > Tunnel convergence is not well defined, in our chairs' evaluation we defined it as the problem of multiple LMAs sending duplicate multicast data to IGMP/MLD Proxy. I think it is better to stick to this definition and separate the avalanche from tunnel convergence. MR at the MAG does solve both avalanche and tunnel convergence problems. I agree with Jouni, Thomas, Guang and the others here. The subscriptions are sent through the MAG-LMA tunnel, and the data is delivered through the MAG-LMA tunnel. Are you saying that is not remote subscription? Charter says: must assume an unmodified mobile host. The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. If IGMP/MLD proxy solves additional problems, that is a bonus! The basic solution should not have additional complexity to solve additional problems, but the proxy solution is one of the basic solutions people have found to the problem. At the wg meeting we had consensus (none against) for choosing the proxy approach as our basic multicast solution. So please let's proceed with that. We should verify that we have consensus (or at least rough consensus) on the mailing list too though. I can send an email to check list consensus, Stig > > Regards, > > Behcet > > > > ----- Original Message ---- >> From: Thomas C. Schmidt >> To: Behcet Sarikaya >> Cc: multimob@ietf.org >> Sent: Thu, November 19, 2009 11:24:34 AM >> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >> >> Hi Behcet, >> >> from my perspective, there are two answers to this: >> >> 1. The sense of the charter is to produce (good) solutions without protocol >> modifications. If the wording of the charter is misleading, we have to follow >> its sense ... as Jari said: there are no holy words in the charter, Multimob >> should attempt to do serious, good work fast! >> >> 2. IMHO, there is no issue with charter words: >> - the term "Remote Subscription" as defined in the literature (-> see >> problem statement) >> was coined as counterpart to "home subscription" (HA-Tunneling). All the >> approaches we >> have been discussing in Hiroshima are of type "remote subscription". >> - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel convergence >> problems in full. >> But even if it did (without protocol modification), that would be fine and >> in no >> contradiction with the charter - as the charter just singles out >> optimizations that do >> change protocols. >> >> In conclusion: you should not debate this artifact. It is a pure waste of time >> and drives the group away from serious work and momentum to solutions. >> >> Cheers >> >> Thomas >> >> Behcet Sarikaya wrote: >>> Hello Folks, >>> Stig and I have been debating this issue, maybe it is time to talk about this >> now: There is an opinion that >>> IGMP/MLD Proxy at the MAG is not in the current charter >>> >>> due to >>> >>> 1. Charter requires remote subscription technique and IGMP/MLD Proxy is not >> exactly remote subscription, >>> 2. Charter says optimizations to deal with avalanche problem will be dealt >> with after rechartering (the last clause in the charter). >>> IGMP/MLD Proxy solves avalanche problem. >>> >>> Regards, >>> >>> Behcet >>> >>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >> -- >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Fri Nov 20 13:16:23 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C422E3A6938 for ; Fri, 20 Nov 2009 13:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVzBmU41-Jgl for ; Fri, 20 Nov 2009 13:16:23 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 0984D3A6919 for ; Fri, 20 Nov 2009 13:16:22 -0800 (PST) Received: (qmail 57886 invoked by uid 60001); 20 Nov 2009 21:16:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258751778; bh=8DT8jRQhG7N3EyZuDnvhJRu0J/K9XMK5oggp2nUKV58=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v501bZIUBgP5YuQiqCl+unE+V+7oHl/K81NtKcKhyKNSSfqxgJkjrekPgQ94sgDbyA4k3T/RVfEN6IZTdzXBWOtLCrqqxk7ZxdzU/n+GZbiAMVkGI5ysC2aj1VgVSMfzrEe7XhJL/kHOVywFp5sEZ8jvQHM4GuCMqJR8B0pk8OI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YDoB+JoniMhJwP6RA0R9h2+/c4Dbo5iRnfoWc42ennQ8O+2km1vHNz1UUEF2V0X0C6033274JnwHm5iCDuz6EQgZZvx+8A7P1gjPMPdgiVoj+f7dguEpEfj9slE1k66Dw+kRvcJ9z8hSyghDi1+/CZPK9QF/K9Gur632b/B/5hk=; Message-ID: <7336.56464.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: GiUwtHcVM1kEC1bQOENlMmSLujMgE9LbgXh2J5r_Rr3prgDcdKi4pUKp Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Fri, 20 Nov 2009 13:16:17 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <4B057F52.8010208@informatik.haw-hamburg.de> <28852.3922.qm@web111405.mail.gq1.yahoo.com> <4B0702EB.3090502@venaas.com> Date: Fri, 20 Nov 2009 13:16:17 -0800 (PST) From: Behcet Sarikaya To: Stig Venaas In-Reply-To: <4B0702EB.3090502@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:16:23 -0000 ----- Original Message ----=0A> From: Stig Venaas =0A> To:= Behcet Sarikaya =0A> Cc: Thomas C. Schmidt ; multimob@ietf.org=0A> Sent: Fri, November 20, 2009= 2:58:19 PM=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A> = Behcet Sarikaya wrote:=0A> > Hi Thomas,=0A> > =0A> >=A0 Remote subscription= together with dealing with avalanche problem after =0A> rechartering means= remote subscription and bi-directional tunneling as described =0A> in draf= t-irtf-mobopts-mmcastv6-ps-09.txt.=0A> > =0A> >=A0 It is true that the char= ter did not spell out bi-directional tunneling, but =0A> it is implied, I d= on't think the charter needed to do this, right? It was out =0A> for review= by public, we received no comments for further clarification.=0A> > =0A> >= =A0 Thomas, I think it is clear that IGMP/MLD Proxy or MR at the MAG approa= ches =0A> do solve the avalanche problem.=0A> > =0A> >=A0 Tunnel convergenc= e is not well defined, in our chairs' evaluation we defined =0A> it as the = problem of multiple LMAs sending duplicate multicast data to IGMP/MLD =0A> = Proxy. I think it is better to stick to this definition and separate the = =0A> avalanche from tunnel convergence. MR at the MAG does solve both avala= nche and =0A> tunnel convergence problems.=0A> =0A> I agree with Jouni, Tho= mas, Guang and the others here. The subscriptions=0A> are sent through the = MAG-LMA tunnel, and the data is delivered through=0A> the MAG-LMA tunnel. A= re you saying that is not remote subscription?=0A=0A=0ALet me reply with a = question then: Are you saying that bi-directional tunneling is not remote s= ubscription?=0A=0A=0A=0A> =0A> Charter says:=0A> =0A> =A0 must assume an un= modified mobile host. The work will employ the remote=0A> =A0 subscription = model. This is a mechanism by which a mobile node joins a=0A> =A0 multicast= group and receives multicast data forwarded via the local=0A> =A0 mobility= anchor.=0A> =0A> If IGMP/MLD proxy solves additional problems, that is a b= onus! The basic=0A> solution should not have additional complexity to solve= additional=0A> problems, but the proxy solution is one of the basic soluti= ons people=0A> have found to the problem.=0A=0AThe charter also says that o= ptimizations including avalanche problem will be solved with rechartering. = =0AAre you saying that IGMP/MLD proxy does not solve avalanche problem?=0A= =0AThis is the main point. As I mentioned, the two together clearly points = to remote subscription + bi-directional tunneling.=0A=0ASo are you saying t= hat we can take the parts of the charter we like and then ignore the parts = we don't like?=0A=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From schmidt@informatik.haw-hamburg.de Fri Nov 20 13:36:55 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E633A680E for ; Fri, 20 Nov 2009 13:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4p8CpkJOw6y for ; Fri, 20 Nov 2009 13:36:54 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 024AA3A6919 for ; Fri, 20 Nov 2009 13:36:52 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178176065.adsl.alicedsl.de ([85.178.176.65] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NBb9s-000FcV-PF; Fri, 20 Nov 2009 22:36:49 +0100 Message-ID: <4B070BEC.9090103@informatik.haw-hamburg.de> Date: Fri, 20 Nov 2009 22:36:44 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <4B057F52.8010208@informatik.haw-hamburg.de> <28852.3922.qm@web111405.mail.gq1.yahoo.com> <4B0702EB.3090502@venaas.com> In-Reply-To: <4B0702EB.3090502@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:36:55 -0000 Hi Stig et al., being just busy working on Multimob drafts, I tend to suggest terminating the discussion on this "How remote must be something to be called remote subscription". People (operators) in the field might be happy to receive guidelines from us on how to deploy multicast easily and in an efficient manner. They most certainly will not care about whether our charter intended to say "far remote", "somewhat remote" or "a little remote" when mentioning "remote subscription". Similarly, I cannot believe that a good, solid solution worked out by the WG will be rejected by the IESG because the "degree of remoteness" is not right. However, @Behcet: if you feel uncertain about the exact interpretation of "remoteness" in the charter, I would suggest to consult Jari about it. I'm sure he'll provide good arguments why it is helpful to relax this sacrosanct exegesis. From the perspective of identifying technically feasible solutions, I cannot sense any spirit of inspiration from these considerations. So let's all have a good, relaxing weekend and a fresh start to fruitful new work on Monday! Cheers, Thomas Stig Venaas wrote: > Behcet Sarikaya wrote: >> Hi Thomas, >> >> Remote subscription together with dealing with avalanche problem >> after rechartering means remote subscription and bi-directional >> tunneling as described in draft-irtf-mobopts-mmcastv6-ps-09.txt. >> >> It is true that the charter did not spell out bi-directional >> tunneling, but it is implied, I don't think the charter needed to do >> this, right? It was out for review by public, we received no comments >> for further clarification. >> >> Thomas, I think it is clear that IGMP/MLD Proxy or MR at the MAG >> approaches do solve the avalanche problem. >> >> Tunnel convergence is not well defined, in our chairs' evaluation we >> defined it as the problem of multiple LMAs sending duplicate multicast >> data to IGMP/MLD Proxy. I think it is better to stick to this >> definition and separate the avalanche from tunnel convergence. MR at >> the MAG does solve both avalanche and tunnel convergence problems. > > I agree with Jouni, Thomas, Guang and the others here. The subscriptions > are sent through the MAG-LMA tunnel, and the data is delivered through > the MAG-LMA tunnel. Are you saying that is not remote subscription? > > Charter says: > > must assume an unmodified mobile host. The work will employ the remote > subscription model. This is a mechanism by which a mobile node joins a > multicast group and receives multicast data forwarded via the local > mobility anchor. > > If IGMP/MLD proxy solves additional problems, that is a bonus! The basic > solution should not have additional complexity to solve additional > problems, but the proxy solution is one of the basic solutions people > have found to the problem. > > At the wg meeting we had consensus (none against) for choosing the proxy > approach as our basic multicast solution. So please let's proceed with > that. We should verify that we have consensus (or at least rough > consensus) on the mailing list too though. > > I can send an email to check list consensus, > > Stig > >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >>> From: Thomas C. Schmidt >>> To: Behcet Sarikaya >>> Cc: multimob@ietf.org >>> Sent: Thu, November 19, 2009 11:24:34 AM >>> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >>> >>> Hi Behcet, >>> >>> from my perspective, there are two answers to this: >>> >>> 1. The sense of the charter is to produce (good) solutions without >>> protocol modifications. If the wording of the charter is misleading, >>> we have to follow its sense ... as Jari said: there are no holy words >>> in the charter, Multimob should attempt to do serious, good work fast! >>> >>> 2. IMHO, there is no issue with charter words: >>> - the term "Remote Subscription" as defined in the literature (-> >>> see problem statement) >>> was coined as counterpart to "home subscription" >>> (HA-Tunneling). All the approaches we >>> have been discussing in Hiroshima are of type "remote >>> subscription". >>> - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel >>> convergence problems in full. >>> But even if it did (without protocol modification), that would >>> be fine and in no >>> contradiction with the charter - as the charter just singles >>> out optimizations that do >>> change protocols. >>> >>> In conclusion: you should not debate this artifact. It is a pure >>> waste of time and drives the group away from serious work and >>> momentum to solutions. >>> >>> Cheers >>> >>> Thomas >>> >>> Behcet Sarikaya wrote: >>>> Hello Folks, >>>> Stig and I have been debating this issue, maybe it is time to talk >>>> about this >>> now: There is an opinion that >>>> IGMP/MLD Proxy at the MAG is not in the current charter >>>> >>>> due to >>>> >>>> 1. Charter requires remote subscription technique and IGMP/MLD Proxy >>>> is not >>> exactly remote subscription, >>>> 2. Charter says optimizations to deal with avalanche problem will be >>>> dealt >>> with after rechartering (the last clause in the charter). >>>> IGMP/MLD Proxy solves avalanche problem. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> _______________________________________________ >>>> multimob mailing list >>>> multimob@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multimob >>> -- >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences Berliner >>> Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>> Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: >>> +49-40-42875-8452 ° >>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>> +49-40-42875-8409 ° >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Fri Nov 20 19:25:01 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E1E3A68EE for ; Fri, 20 Nov 2009 19:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIsCNDKs9+Oj for ; Fri, 20 Nov 2009 19:25:00 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id BEBA83A67A4 for ; Fri, 20 Nov 2009 19:25:00 -0800 (PST) Received: (qmail 70059 invoked by uid 60001); 21 Nov 2009 03:24:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258773895; bh=+mTOrfpIc6mNJmTftZzUTsr7hyADZHkBEdcIKJORSFU=; 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=qLzB1EGgXU89jSCnGkH1cQzq/raKhyLWwNAY7wBSLt0sac1NVLYnw3AFPpCIkQ36pkNvi40U1cJ7YdJu4mhip6+lVCVu4T9QKQF0uCvm8RQma2JuRAuEuy4L3gX3ThxCtQo3rXcJ3WCyQvObgPpkodM87wdGmaH84AhD/65bTnU= 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=TxgoGZxpaE4+67PwS7dqqFzlnNkRzH21OcA/Is9ULa81P/2RMsGx9O1/LErStVqw252SaI4ms6v/JhnyXhujppHpE8D5EjLbPiCtFoU0WmQy1SZ8XqQ2qDxqNBqwqROjdtsJznJ+3OUTnvAEOzPIQxsu1WCaUDpoblAyNUtRuTw=; Message-ID: <555186.69483.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: 4YVsLMsVM1lCaAQ9UwkizArXm_wis5.Jlf1V.JFyWJkLo3X.bYW9Ga17xZ1oHRfEIF0wffFNpndVUtSDh3aDt.9yQ3tCL19hDhdStAi2eCBnOB_KfZeX5BIkM0Cg7Y1y6sH7CPXPY1OjDie8xsAg8V5f3jY_h4iEs8PzhMdcmxnt_WfMEXtnoA0akcEGx7YZZa0H4F9jb0dck56a3tnQL_40RiBGtaKaSEfEk0S3qxpMoA8jLJdtwD.SLw16hrIoQeICbGp7tbi_D52ZX01QihxaIM5hDRcCeJfgFCDgKVrqA7efvT50VqHRicQKzkIz_5pF2tT9uNM1F.k3Gb2633G9woLj7sJcypyz.HB_ Received: from [72.64.108.212] by web111406.mail.gq1.yahoo.com via HTTP; Fri, 20 Nov 2009 19:24:55 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> Date: Fri, 20 Nov 2009 19:24:55 -0800 (PST) From: Behcet Sarikaya To: jouni In-Reply-To: <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 03:25:01 -0000 Hi Jouni, ________________________________ From: jouni To: Behcet Sarikaya Cc: multimob@ietf.org Sent: Thu, November 19, 2009 5:31:52 PM Subject: Re: [multimob] IGMP/MLD Proxy at the MAG Hi Behcet, On Nov 19, 2009, at 7:13 PM, Behcet Sarikaya wrote: > Hello Folks, > Stig and I have been debating this issue, maybe it is time to talk about this now: There is an opinion that > > IGMP/MLD Proxy at the MAG is not in the current charter > > due to > > 1. Charter requires remote subscription technique and IGMP/MLD Proxy is not exactly remote subscription, >From the current charter: > Specific goals for the group are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment The above does not prevent us working on a MLD Proxy based solution or any other solution. And if the solution, be that MLD Proxy or something else, works also in a mode where all data comes through LMA, the remote subscription requirement is also met. [behcet] There are two kinds of MLD Proxies: Independent MLD Proxy at the MAG or MLD Proxy at the MAG integrated with LMA. The former case would work independent of PMIPv6 so it is not our concern. What we are talking about is MLD Proxy integrated with LMA. In this case MLD Proxy at the MAG communicates with LMA over MAG-LMA tunnel as in PMIPv6. MLD Proxy sends aggregated joins as MLD reports to LMA as MR. All LMA as MR cares is which downstream interface is interested in which multicast groups so that LMA can tunnel multicast data into that downstream interface. It does not know anything about individual MNs. The charter says: The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor.Can we call this solution remote subscription as defined above? I find it difficult to do so. > > 2. Charter says optimizations to deal with avalanche problem will be dealt with after rechartering (the last clause in the charter). > IGMP/MLD Proxy solves avalanche problem. I am confused. What this has to do with optimizations? As far as I understand it now, MLD Proxy seems to address the following charter requirements: "This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host." This can of course change if we get/find new facts that state opposite. [behcet] Optimization here is compared with bi-directional tunneling and remote subscription. Clearly MLD Proxy at the MAG integrated with LMA is an optimization because LMA sends one copy for the whole group which may have many members. And the charter says the optimizations are left to rechartering. Hope the above clarifies my points. Regards, Behcet From stig@venaas.com Mon Nov 23 11:40:08 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068D43A6A8F for ; Mon, 23 Nov 2009 11:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUTnp89xI3Rp for ; Mon, 23 Nov 2009 11:40:07 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 22E023A6A1B for ; Mon, 23 Nov 2009 11:40:06 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 1BE0221D1A; Mon, 23 Nov 2009 20:39:59 +0100 (CET) Message-ID: <4B0AE50D.4020905@venaas.com> Date: Mon, 23 Nov 2009 11:39:57 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <555186.69483.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:40:08 -0000 Behcet Sarikaya wrote: > Hi Jouni, > ________________________________ > From: jouni > To: Behcet Sarikaya > Cc: multimob@ietf.org > Sent: Thu, November 19, 2009 5:31:52 PM > Subject: Re: [multimob] IGMP/MLD Proxy at the MAG > > Hi Behcet, > > On Nov 19, 2009, at 7:13 PM, Behcet Sarikaya wrote: > >> Hello Folks, >> Stig and I have been debating this issue, maybe it is time to talk about this now: There is an opinion that >> >> IGMP/MLD Proxy at the MAG is not in the current charter >> >> due to >> >> 1. Charter requires remote subscription technique and IGMP/MLD Proxy is not exactly remote subscription, > >>From the current charter: > >> Specific goals for the group are: >> - Document how multicast can be supported in a Proxy Mobile IPv6 >> environment > > The above does not prevent us working on a MLD Proxy based solution or any other solution. And if the solution, be that MLD Proxy or something else, works also in a mode where all data comes through LMA, the remote subscription requirement is also met. > > [behcet] There are two kinds of MLD Proxies: Independent MLD Proxy at the MAG or MLD Proxy at the MAG integrated with LMA. The former case would work independent of PMIPv6 so it is not our concern. What we are talking about is MLD Proxy integrated with LMA. In this case MLD Proxy at the MAG communicates with LMA over MAG-LMA tunnel as in PMIPv6. MLD Proxy sends aggregated joins as MLD reports to LMA as MR. All LMA as MR cares is which downstream interface is interested in which multicast groups so that LMA can tunnel multicast data into that downstream interface. It does not know anything about individual MNs. I would say here that the only difference is whether the upstream interface is to a local router or if it is the MAG-LMA tunnel. The nice thing is that the operation of the proxy is the same, so it makes it easy to support both models. > The charter says: > > The work will employ the remote > subscription model. This is a mechanism by which a mobile node joins a > multicast group and receives multicast data forwarded via the local > mobility anchor.Can we call this solution remote subscription as defined above? I find it difficult to do so. I think so. What you quote here is exactly what happens in the MLD proxy case (where the proxy uses MAG-LMA tunnel as upstream). >> 2. Charter says optimizations to deal with avalanche problem will be dealt with after rechartering (the last clause in the charter). >> IGMP/MLD Proxy solves avalanche problem. > > I am confused. What this has to do with optimizations? As far as I understand it now, MLD Proxy seems to address the following charter requirements: "This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host." This can of course change if we get/find new facts that state opposite. > > > [behcet] Optimization here is compared with bi-directional tunneling and remote subscription. Clearly MLD Proxy at the MAG integrated with LMA is an optimization because LMA sends one copy for the whole group which may have many members. > And the charter says the optimizations are left to rechartering. IMO this is not optimization, it is simply multicast. We want to do multicast, and the we only want to do replication where the topology branches out. Which means replication at the MAG. I also want to say that I think the intention of the charter, is that we work on a basic solution that is as simple as possible. Where we don't add complexity by trying to solve more than just basic multicast. IMO the MLD proxy solution is the simplest possible remote subscription solution. There may be other solutions, e.g. doing replication at the LMA, but unless they are simpler solutions, why would we do that and lose the main benefit of multicast? Are there any technical reasons for doing replication at the LMA instead of the MAG? Stig > Hope the above clarifies my points. > > Regards, > > Behcet > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon Nov 23 12:45:59 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA423A68EF for ; Mon, 23 Nov 2009 12:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7t9AEKs+ZCY for ; Mon, 23 Nov 2009 12:45:58 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id A86F33A68C3 for ; Mon, 23 Nov 2009 12:45:58 -0800 (PST) Received: (qmail 1894 invoked by uid 60001); 23 Nov 2009 20:45:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259009152; bh=MBw+V4GiSMJ48fj/CqeCrkHfdG1oWCMt9piHkp48p2w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6WOh0Xj/K9eey8KXRzx8pI/5HGkji7nL1A1VHbjZwFGDtm2vuKdyxvPObHYgbXw9RTtaVlMQB7UfUTmdt9VX8WXRX2l/ff3Df9b8uploaJOUhQVGzlWlMCT0Kqcvcpv1vnxbZdWEKmwgCtO2Wnj+wc9tG0HNbH6higZMjICi3aA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JlmRcFNr1yFg5vyLkgYzET4Op9NJWGQnhI6UMErkgiSVMp16pc4nTHHivHxZPPt7CSGlIUQ0/duO6gygLJcsM0P+oy5NRUFcva1n91dx1wC0/zRoEh8l9CKjHemX+pzTJvFk2CR6YumBun16A3b3qKfN8YHb4+9+dp/3R03aYQQ=; Message-ID: <265527.1173.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: rifmZjAVM1nv9UpEUV6QKesFnNeHiqVBj1RnI5e6TE9WUF5ndeWVf7vOUfFAPP6Phw2O5uZnfuZadH8y1lAeiE46Rwx41Rd0LwKhRNAmBNafmy8oVgJI7Ne8q6aRXuI5YHxaQ1zThaQPokAEeJ5g3T_4sEYh.HvoDzxHqBrZKM2CySl55fEOQO8rb9bgeYt_a5GQLMdlD4d_qkU1soczj.rQrNt0EUgj.nTHST007_LX6giJeZTgBXtLxU3YEdHV8ANTa3zNB.sRTRG7sgoaXEcFX8VLUSGuEqibDJkXUU7Ex8yE7izNJVSQiw0I8pUL87keEa1FG67WbzFztOeyuq9R9ddfdA5LvIdpxH5G8DvGvx7_pd6liUuPfkOGf1tBZYMi3CB3Ztv50QMEVkQWJ5x9qHfQqYB2cTks Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Mon, 23 Nov 2009 12:45:52 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><4B057F52.8010208@informatik.haw-hamburg.de> <1258674901.4074.57.camel@acorde.it.uc3m.es> Date: Mon, 23 Nov 2009 12:45:52 -0800 (PST) From: Behcet Sarikaya To: "Lu, Guang" , multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:45:59 -0000 Hi Guang,=0A=A0 We have several PMIPv6 solution drafts. We appreciate the w= ork presented in these drafts. The current discussion is a charter discussi= on to see which direction is the right one for the charter items. =0A=A0 So= lution drafts are useful on their own virtue maybe not necessarily at this = stage but certainly in some future stages.=0A=A0 Please don't get a wrong i= mpression from the current discussion.=0A=0AKeep up the good work.=0A=0ABeh= cet=0A=0A=0A=0A----- Original Message ----=0A> From: "Lu, Guang" =0A> To: multimob@ietf.org=0A> Sent: Fri, November 20, 200= 9 10:13:42 AM=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A= > We also agree with the reasoning by Thomas and Jouni. =0A> =0A> Best rega= rds,=0A> Guang & Juan Carlos=0A> =0A> > -----Original Message-----=0A> > Fr= om: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On=0A> > B= ehalf Of Carlos Jes=FAs Bernardos Cano=0A> > Sent: Thursday, November 19, 2= 009 6:55 PM=0A> > To: Thomas C. Schmidt=0A> > Cc: multimob@ietf.org=0A> > S= ubject: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> > =0A> > Agree.=0A> > = =0A> > Carlos=0A> > =0A> > On Thu, 2009-11-19 at 18:24 +0100, Thomas C. Sch= midt wrote:=0A> > > Hi Behcet,=0A> > >=0A> > > from my perspective, there a= re two answers to this:=0A> > >=0A> > >=A0 1. The sense of the charter is t= o produce (good) solutions without=0A> > > protocol modifications. If the w= ording of the charter is misleading,=0A> > > we have to follow its sense ..= . as Jari said: there are no holy words=0A> > > in the charter, Multimob sh= ould attempt to do serious, good work=0A> > fast!=0A> > >=0A> > >=A0 2. IMH= O, there is no issue with charter words:=0A> > >=A0 =A0 =A0 - the term "Rem= ote Subscription" as defined in the literature (-=0A> > >=0A> > > see probl= em statement)=0A> > >=A0 =A0 =A0 =A0 was coined as counterpart to "home sub= scription" (HA-=0A> > Tunneling).=0A> > > All the approaches we=0A> > >=A0 = =A0 =A0 =A0 have been discussing in Hiroshima are of type "remote=0A> > sub= scription".=0A> > >=A0 =A0 =A0 - IGMP/MLD Proxy at the MAG does not solve a= valanche/tunnel=0A> > > convergence problems in full.=0A> > >=A0 =A0 =A0 = =A0 But even if it did (without protocol modification), that would=0A> > > = be fine and in no=0A> > >=A0 =A0 =A0 =A0 contradiction with the charter - a= s the charter just singles=0A> > > out optimizations that do=0A> > >=A0 =A0= =A0 =A0 change protocols.=0A> > >=0A> > > In conclusion: you should not de= bate this artifact. It is a pure=0A> > waste=0A> > > of time and drives the= group away from serious work and momentum to=0A> > > solutions.=0A> > >=0A= > > > Cheers=0A> > >=0A> > > Thomas=0A> > >=0A> > > Behcet Sarikaya wrote:= =0A> > > > Hello Folks,=0A> > > >=A0 Stig and I have been debating this iss= ue, maybe it is time to=0A> > talk=0A> > > > about this now: There is an op= inion that=0A> > > >=0A> > > > IGMP/MLD Proxy at the MAG is not in the curr= ent charter=0A> > > >=0A> > > > due to=0A> > > >=0A> > > > 1. Charter requi= res remote subscription technique and IGMP/MLD=0A> > Proxy=0A> > > > is not= exactly remote subscription,=0A> > > >=0A> > > > 2. Charter says optimizat= ions to deal with avalanche problem will=0A> > be dealt with after recharte= ring (the last clause in the charter).=0A> > > > IGMP/MLD Proxy solves aval= anche problem.=0A> > > >=0A> > > > Regards,=0A> > > >=0A> > > > Behcet=0A> = > > >=0A> > > >=0A> > > >=0A> > > > _______________________________________= ________=0A> > > > multimob mailing list=0A> > > > multimob@ietf.org=0A> > = > > https://www.ietf.org/mailman/listinfo/multimob=0A> > >=0A> > --=0A> > C= arlos Jes=FAs Bernardos Cano=A0 =A0 http://www.netcoms.net=0A> > GPG FP: D2= 9B 0A6A 639A A561 93CA=A0 4D55 35DC BA4D D170 4F67=0A> ____________________= ___________________________=0A> multimob mailing list=0A> multimob@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From sijeon79@gmail.com Mon Nov 23 23:24:01 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C94D28C0D9 for ; Mon, 23 Nov 2009 23:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VU6KuzjcPWQ for ; Mon, 23 Nov 2009 23:24:00 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 5035428C0D7 for ; Mon, 23 Nov 2009 23:24:00 -0800 (PST) Received: by pzk4 with SMTP id 4so4236811pzk.32 for ; Mon, 23 Nov 2009 23:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=IVXJlxm5b946UR95va5+Q8Z4z4RTAsqgCtAB6FXAFnk=; b=JTd4H4tzdbfgjfuaHb5r3BauZOekGbCKI+Ipq1LR10b+Uz23QebiLa6SAyXPr5jgpW d8grSlsKjdQfKXIp6TTFJ7wdeuetUzPvUlYW3mWTlD6xrHgSbrlOywtCSX2K4FkBpKjR Btx+alghPSV+JSe2HYK6VYDkt+Ks+Adx3NvJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:in-reply-to:x-mimeole; b=XdkYhTgFJXo9tV0rZbD3FEDH4TaRw8NbUR7x9ROk1wjEOPtGABDqxT+2dNNlReF+wU vHd0cMxBWCZEMATbT5CRbgtzVUQ/qy6E7Qd+zhW+8+T+i9j5Zu0F3wRojwD7BF1GAAJ8 pWaPXsSPRh+Q+jD8Ov7QSN2x9OlnA8tzVtY8I= Received: by 10.115.135.23 with SMTP id m23mr11431670wan.136.1259047433677; Mon, 23 Nov 2009 23:23:53 -0800 (PST) Received: from dcn0d4b06d5df0 ([220.149.84.225]) by mx.google.com with ESMTPS id 23sm3274297pxi.13.2009.11.23.23.23.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 23:23:51 -0800 (PST) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> Date: Tue, 24 Nov 2009 16:23:46 +0900 Organization: dcn Message-ID: <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpqWjkJ9kGs3mLoQ1eI5Dzx2xZ//ACdx72A In-Reply-To: <555186.69483.qm@web111406.mail.gq1.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 07:24:01 -0000 Hi Behcet, Please see below [Seil Jeon]. -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Saturday, November 21, 2009 12:25 PM To: jouni Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG Hi Jouni, ________________________________ From: jouni To: Behcet Sarikaya Cc: multimob@ietf.org Sent: Thu, November 19, 2009 5:31:52 PM Subject: Re: [multimob] IGMP/MLD Proxy at the MAG Hi Behcet, On Nov 19, 2009, at 7:13 PM, Behcet Sarikaya wrote: > Hello Folks, > Stig and I have been debating this issue, maybe it is time to talk > about this now: There is an opinion that > > IGMP/MLD Proxy at the MAG is not in the current charter > > due to > > 1. Charter requires remote subscription technique and IGMP/MLD Proxy > is not exactly remote subscription, >From the current charter: > Specific goals for the group are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment The above does not prevent us working on a MLD Proxy based solution or any other solution. And if the solution, be that MLD Proxy or something else, works also in a mode where all data comes through LMA, the remote subscription requirement is also met. [behcet] There are two kinds of MLD Proxies: Independent MLD Proxy at the MAG or MLD Proxy at the MAG integrated with LMA. The former case would work independent of PMIPv6 so it is not our concern. What we are talking about is MLD Proxy integrated with LMA. In this case MLD Proxy at the MAG communicates with LMA over MAG-LMA tunnel as in PMIPv6. MLD Proxy sends aggregated joins as MLD reports to LMA as MR. All LMA as MR cares is which downstream interface is interested in which multicast groups so that LMA can tunnel multicast data into that downstream interface. It does not know anything about individual MNs. => [Seil Jeon] Why a LMA have to know individual MN's state in multicasting? In the perspective of multicasting (LMA is MR), a LMA only needs information whether there is a listener or not. And I want to know your solution exactly.. both MR are located MAG and LMA? The charter says: The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor.Can we call this solution remote subscription as defined above? I find it difficult to do so. > > 2. Charter says optimizations to deal with avalanche problem will be dealt with after rechartering (the last clause in the charter). > IGMP/MLD Proxy solves avalanche problem. I am confused. What this has to do with optimizations? As far as I understand it now, MLD Proxy seems to address the following charter requirements: "This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host." This can of course change if we get/find new facts that state opposite. [behcet] Optimization here is compared with bi-directional tunneling and remote subscription. Clearly MLD Proxy at the MAG integrated with LMA is an optimization because LMA sends one copy for the whole group which may have many members. And the charter says the optimizations are left to rechartering. => [Seil Jeon] IMHO, I don't think. We need PMIPv6 multicasting solution not adding PMIPv6 + multicasting. When we consider basic solution for multicasting, we have to find reasonble way as possible, and it is our job. As other folks said, I have no doubt that MLD proxy is simplest possible approach for remote subscription solution. Hope the above clarifies my points. Regards, Behcet _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Tue Nov 24 08:46:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF46928C114 for ; Tue, 24 Nov 2009 08:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voz1uemMFnch for ; Tue, 24 Nov 2009 08:46:09 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id EF9863A67E9 for ; Tue, 24 Nov 2009 08:45:57 -0800 (PST) Received: (qmail 76809 invoked by uid 60001); 24 Nov 2009 16:45:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259081150; bh=gQ0EoOOWTo4/XNqod7ZIQ0ujEYVo6Hes4UmXVLsYYnY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AhIl2XfzXbl5PwSOj9aqxbBOMgeeK1bfIUJp66TWiVFPDSTKQwz6i/qLqD2xqIuMuWdylyy1lVRuHFzMWsQQF4OjAbuImskcBcwF6hlhOVQDNznfheDevVWiyTtHAsyyThtDcg/UYmk/t2+VgcNbkQWuj35Jn1Vc2W39nFNRR90= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x5I3wG0f/wr7CGD+mMMk7LX/Fvvjwqrd4s0TKRNE4oevDahXCYkLJt7vLjYTFM4/7ce1kavQuNa2C4Zk6C1HThFOJrpJKH8to7JuBH96E0H6Hat2KovWaN1zdd2CR9c92KWtUBXiGUy7E9Ek5uhmsWNssFH7g7ImY9RL8LppA5w=; Message-ID: <32541.76745.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: YdebDKwVM1lFPtnqtd07YAOtq3vrPkx78RNiSsPqYDfcISugoKTsfN.CUgVQLodGnH1QDO_I2YyW0AnkDvjWLY3oUr4684_fzTfrcx1rcbPGfaAH4H1SoaV_RSCgF76xr.m4_ymF0At8tCXufE0scfBE4rSKTWYUi95d7hGbmWuHSULG3WklrZc9vY_6o9A2C4ZA.cgt7VnG8T0BA970fwWx3siOSjoEqbOABNvw19MpNTrofXnXaWYpzCxKX5WSBvNHagqSIMFS.IiMCI5xh1j6Ysi8dJw6PKqJT4tcd8wJnNihAkfJ6yC2WRKkSVXuOlaYvZKkFtgnKNGRpp6Z5AHnz0TpTzvL2kAO34wq Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 24 Nov 2009 08:45:49 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> Date: Tue, 24 Nov 2009 08:45:49 -0800 (PST) From: Behcet Sarikaya To: sijeon79@gmail.com In-Reply-To: <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:46:10 -0000 Hi Seil,=0A=0A=0A=0A----- Original Message ----=0A> From: Seil Jeon =0A> To: Behcet Sarikaya =0A> Cc: multimob@= ietf.org=0A> Sent: Tue, November 24, 2009 1:23:46 AM=0A> Subject: RE: [mult= imob] IGMP/MLD Proxy at the MAG=0A> =0A> =0A> Hi Behcet, =0A> =0A> Please s= ee below [Seil Jeon].=0A> =0A> -----Original Message-----=0A> From: multimo= b-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On=0A> Behalf Of Behc= et Sarikaya=0A> Sent: Saturday, November 21, 2009 12:25 PM=0A> To: jouni=0A= > Cc: multimob@ietf.org=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the M= AG=0A> =0A> Hi Jouni,=0A> ________________________________=0A> From: jouni = =0A> To: Behcet Sarikaya =0A> Cc: multimob@ietf.org=0A> Sent: Thu, November= 19, 2009 5:31:52 PM=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG= =0A> =0A> Hi Behcet,=0A> =0A> On Nov 19, 2009, at 7:13 PM, Behcet Sarikaya = wrote:=0A> =0A> > Hello Folks,=0A> >=A0 Stig and I have been debating this = issue, maybe it is time to talk =0A> > about this now: There is an opinion = that=0A> > =0A> > IGMP/MLD Proxy at the MAG is not in the current charter= =0A> > =0A> > due to=0A> > =0A> > 1. Charter requires remote subscription t= echnique and IGMP/MLD Proxy =0A> > is not exactly remote subscription,=0A> = =0A> From the current charter:=0A> =0A> >=A0 Specific goals for the group a= re:=0A> >=A0 - Document how multicast can be supported in a Proxy Mobile IP= v6=0A> >=A0 =A0 environment=0A> =0A> The above does not prevent us working = on a MLD Proxy based solution or any=0A> other solution. And if the solutio= n, be that MLD Proxy or something else,=0A> works also in a mode where all = data comes through LMA, the remote=0A> subscription requirement is also met= .=0A> =0A> [behcet] There are two kinds of MLD Proxies: Independent MLD Pro= xy at the=0A> MAG or MLD Proxy=A0 at the MAG integrated with LMA. The forme= r case would=0A> work independent of PMIPv6 so it is not our concern. What = we are talking=0A> about is MLD Proxy integrated with LMA. In this case MLD= Proxy at the MAG=0A> communicates with LMA over MAG-LMA tunnel as in PMIPv= 6. MLD Proxy sends=0A> aggregated joins as MLD reports to LMA as MR. All LM= A as MR cares is which=0A> downstream interface is interested in which mult= icast groups so that LMA=0A> can tunnel multicast data into that downstream= interface. It does not know=0A> anything about individual MNs.=0A> =0A> = =3D> [Seil Jeon] Why a LMA have to know individual MN's state in multicasti= ng?=0A> =A0 =A0 =A0 In the perspective of multicasting (LMA is MR), a LMA o= nly needs=0A> information whether there is a listener or not.=0A> =A0 =A0 A= nd I want to know your solution exactly.. both MR are located MAG and=0A> L= MA?=0A> =0A=0AThe charter is pointing at a base solution as in MIPv6/MIPv4 = which is characterized as bi-directional tunneling and remote subscription = in draft-irtf-mobopts-mmcastv6-ps-09.txt. This is what I am saying. =0A=0A>= =0A> The charter says:=0A> =0A> The work will employ the remote=0A> =A0 su= bscription model. This is a mechanism by which a mobile node joins a=0A> = =A0 multicast group and receives multicast data forwarded via the local=0A>= =A0 mobility anchor.Can we call this solution remote subscription as defin= ed=0A> above? I find it difficult to do so.=0A> =0A> > =0A> > 2. Charter sa= ys optimizations to deal with avalanche problem will be=0A> dealt with afte= r rechartering (the last clause in the charter).=0A> > IGMP/MLD Proxy solve= s avalanche problem.=0A> =0A> I am confused. What this has to do with optim= izations? As far as I=0A> understand it now, MLD Proxy seems to address the= following charter=0A> requirements: "This work will not require any additi= ons or changes to=0A> message types and parameters specified in RFC 5213, a= nd must assume an=0A> unmodified mobile host." This can of course change if= we get/find new facts=0A> that state opposite.=0A> =0A> =0A> [behcet] Opti= mization here is compared with bi-directional tunneling and=0A> remote subs= cription. Clearly MLD Proxy=A0 at the MAG integrated with LMA is=0A> an opt= imization because LMA sends one copy for the whole group which may=0A> have= many members.=0A> And the charter says the optimizations are left to recha= rtering.=0A> =0A> =3D> [Seil Jeon] IMHO, I don't think. We need PMIPv6 mult= icasting solution=0A> not adding PMIPv6 + multicasting.=0A> =A0 =A0 When we= consider basic solution for multicasting, we have to find=0A> reasonble wa= y as possible, and it is our job.=0A> =A0 =A0 As other folks said, I have n= o doubt that MLD proxy is simplest=0A> possible approach for remote subscri= ption solution.=0A> =0A=0AI think we should understand optimizations lookin= g at the base solution, the optimizations are vis-a-vis the base solution, = we can say that locally available multicast with all variations is an optim= ization. =0A=0AAnother point is: according to RFC 4605, MLD Proxy forwards = multicast data downstream or sends aggregate joins upstream. =0AIf you read= draft-schmidt, =0ABased on the multicast-transparent operations of=0A th= e MAGs, the LMA experiences its tunnel interfaces as multicast=0A enabled= downstream links, serving zero to many listening nodes.=0A Multicast tra= ffic arriving at the LMA is transparently forwarded=0A according to its m= ulticast forwarding information base.=0Atunneling is implicit or has been c= arefully hidden. Isn't this protocol extension?=0ASo I am saying that we sh= ould look at these extensions in the next stage.=0A=0ARegards,=0A=0ABehcet= =0A=0A=0A From schmidt@informatik.haw-hamburg.de Wed Nov 25 12:32:00 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295393A6837 for ; Wed, 25 Nov 2009 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5WTYqg+dBHz for ; Wed, 25 Nov 2009 12:31:59 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id ED3353A6898 for ; Wed, 25 Nov 2009 12:31:56 -0800 (PST) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NDOWj-000Ihz-Io; Wed, 25 Nov 2009 21:31:49 +0100 Message-ID: <4B0D9430.5000308@informatik.haw-hamburg.de> Date: Wed, 25 Nov 2009 21:31:44 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <32541.76745.qm@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:32:00 -0000 Hi Behcet, just a quick word below: Behcet Sarikaya wrote: > Another point is: according to RFC 4605, MLD Proxy forwards multicast data downstream or sends aggregate joins upstream. > If you read draft-schmidt, > Based on the multicast-transparent operations of > the MAGs, the LMA experiences its tunnel interfaces as multicast > enabled downstream links, serving zero to many listening nodes. > Multicast traffic arriving at the LMA is transparently forwarded > according to its multicast forwarding information base. > tunneling is implicit or has been carefully hidden. Isn't this protocol extension? > So I am saying that we should look at these extensions in the next stage. Thanks for reading carefully :-) But I don't get your point: This passage describes how a router (such as LMA) forwards multicast data to its downstream interfaces according to its MFIB. The tunnel interface is seen as an interface that does encapsulation, implicitly or explicitly, but the interface is not hidden (it's also used for PMIP unicast). The use of PMIP tunnels is certainly not a protocol extension. It is actually the PMIP way to shift traffic between LMA & MAG. So nothing new here - it's just Internet routing. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jouni.nospam@gmail.com Wed Nov 25 13:55:57 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A939E3A687D for ; Wed, 25 Nov 2009 13:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGfb2Cv2fKqQ for ; Wed, 25 Nov 2009 13:55:56 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 5F0B63A6852 for ; Wed, 25 Nov 2009 13:55:56 -0800 (PST) Received: by bwz23 with SMTP id 23so141402bwz.29 for ; Wed, 25 Nov 2009 13:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=uGGXyEBm1EOSlZJvH2R1Dxdw+xFk/BIiJTGxrUAyc/o=; b=W+9CaqSxMQB1GFGQvYin8WwM0SMF1/VsmHAjDmb3ldz2tgejpWVsw2MZYGR67HxPY9 Y3S8Vf+Wgxsdl7pQceedKJdnwi/nbwLCJHvBiyz4cqLo7pbr79pjnjw0Sg3u/Us9J4LA 9WNhQfUEcS+vDsE2QRcjpE+TRmBJ2uVj6/27w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=J6wrkOPdcC3lsLpFcSdCu3z9FzJYm/WJncvPtbHEG8DF7fJ6UUYc4Jo1bRlE3un+9q BoGGGWbMRsToDGZvlt8H0ldYofa9gT0mHdepQA45GW2JeYyNvxdZh4vlQjC94IaINtnP ZxM2arKSKJhAw0iViCfhBQ6dPvWfKubsOg2/Q= Received: by 10.204.151.210 with SMTP id d18mr2790611bkw.203.1259186147224; Wed, 25 Nov 2009 13:55:47 -0800 (PST) Received: from a88-112-205-101.elisa-laajakaista.fi (a88-112-205-101.elisa-laajakaista.fi [88.112.205.101]) by mx.google.com with ESMTPS id 22sm71256fkq.54.2009.11.25.13.55.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 13:55:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <32541.76745.qm@web111414.mail.gq1.yahoo.com> Date: Wed, 25 Nov 2009 23:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18166C82-51AD-440F-97A0-0B493B49E731@gmail.com> References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1077) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:55:57 -0000 Hi Behcet, On Nov 24, 2009, at 6:45 PM, Behcet Sarikaya wrote: [snip] >>=20 >> [behcet] Optimization here is compared with bi-directional tunneling = and >> remote subscription. Clearly MLD Proxy at the MAG integrated with = LMA is >> an optimization because LMA sends one copy for the whole group which = may >> have many members. >> And the charter says the optimizations are left to rechartering. >>=20 >> =3D> [Seil Jeon] IMHO, I don't think. We need PMIPv6 multicasting = solution >> not adding PMIPv6 + multicasting. >> When we consider basic solution for multicasting, we have to find >> reasonble way as possible, and it is our job. >> As other folks said, I have no doubt that MLD proxy is simplest >> possible approach for remote subscription solution. >>=20 >=20 > I think we should understand optimizations looking at the base = solution, the optimizations are vis-a-vis the base solution, we can say = that locally available multicast with all variations is an optimization.=20= >=20 > Another point is: according to RFC 4605, MLD Proxy forwards multicast = data downstream or sends aggregate joins upstream.=20 > If you read draft-schmidt,=20 > Based on the multicast-transparent operations of > the MAGs, the LMA experiences its tunnel interfaces as multicast > enabled downstream links, serving zero to many listening nodes. > Multicast traffic arriving at the LMA is transparently forwarded > according to its multicast forwarding information base. > tunneling is implicit or has been carefully hidden. Isn't this = protocol extension? > So I am saying that we should look at these extensions in the next = stage. The MLD Proxy proposal is aligned with RFC5213 way of doing MAG-LMA = tunneling. For non-multicast (unicast) traffic there is also one tunnel, = which aggregates traffic for multiple MNs between the MAG-LMA. The = tunnel interfaces are not "carefully" hidden in any way, for unicast or = multicast traffic. What is needed in case of multicast, is having proper = route entries pointing to tunnel interfaces in both MAG and LMA side, = and SPD entries to match proper type of traffic. I fail to see this as = an protocol extension. Furthermore, I don't understand why we would need = to come up with a clearly inferior solution when there is a better one = available, which even seems to fit into the existing protocol solution. Cheers, Jouni >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Wed Nov 25 14:13:23 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C3F3A6B45 for ; Wed, 25 Nov 2009 14:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrLzG95GpeOg for ; Wed, 25 Nov 2009 14:13:23 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 125A03A687D for ; Wed, 25 Nov 2009 14:13:23 -0800 (PST) Received: (qmail 72358 invoked by uid 60001); 25 Nov 2009 22:13:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259187195; bh=aTdIYKxpgX9hdNebSHfOdKJ/E15OEZVUjYmbDWX9IAA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KEfmzExR4+xY/7xGEl0r5o/yq0LURwFqafK43uQNOUA4M9ljpWtFQRLQkmVcs6uO5QoQJT6iT1y+qAGJnAK0rySTubNW7mMnofL6mHbVUWh2i0EYVq70ng1RR9BA6D8QnisXPm7D9MdtXmT308Az3dvpdK7QmrlD3XulxJy+sX8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rBZ2/5bym3u2WQEBLrzUIVuDApy3Y5ubgdH1jGN8VLNvmPoBn5G4MkC5Paa4X+kaLg8f0zbZtg36hTl4ECtj68pLxp4TkO1L6F/VRMMvD+rVwTZ7i/QtfJyAIqt0dM1mo0UjOrqMr3e+YEQ5iQpb1cxH9Cp59+GZKZHWClYejWs=; Message-ID: <74406.71791.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: 8szyQV8VM1lk8A0.vo0QxswLvwncPBmAni4t8.FA9dpeBJf_oHlB96wZxfNlrcO91JCQmNMsOPKhF49fsqaNtg37GeBNt7IW6QhY.5yk7jhNR3q3Y14MuO0sjNWhgLucudf_66iOQr6RdDMR.szS5cgyE6.djgfSp3RU.srGQIDR8DNT0WWU8aKEJO4pz1tWz9dH5XlZCXqEMfmVZ9QOTPxFFduJeItXMVs7oQv9.qHmfqDI8ovxLqh6GJCdoaUYI5nPx4jekbrlCox8TTof09y6oNmmUUkqvns7QovFDSmrXBHh9CPVggFGZarGqQOjcpEWwlCtJG1wObMgmu4mIk.x92WSFa_woLfWN5Wy Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 25 Nov 2009 14:13:14 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> Date: Wed, 25 Nov 2009 14:13:14 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4B0D9430.5000308@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:13:24 -0000 Hi Thomas,=0A=0A=0A=0A----- Original Message ----=0A> From: Thomas C. Schmi= dt =0A> To: Behcet Sarikaya =0A> Cc: sijeon79@gmail.com; multimob@ietf.org=0A> Sent: Wed, Novemb= er 25, 2009 2:31:44 PM=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the MA= G=0A> =0A> Hi Behcet,=0A> =0A> just a quick word below:=0A> =0A> Behcet Sar= ikaya wrote:=0A> =0A> > Another point is: according to RFC 4605, MLD Proxy = forwards multicast data =0A> downstream or sends aggregate joins upstream. = If you read draft-schmidt, Based =0A> on the multicast-transparent operatio= ns of=0A> >=A0 =A0 the MAGs, the LMA experiences its tunnel interfaces as m= ulticast=0A> >=A0 =A0 enabled downstream links, serving zero to many listen= ing nodes.=0A> >=A0 =A0 Multicast traffic arriving at the LMA is transparen= tly forwarded=0A> >=A0 =A0 according to its multicast forwarding informatio= n base.=0A> > tunneling is implicit or has been carefully hidden. Isn't thi= s protocol =0A> extension?=0A> > So I am saying that we should look at thes= e extensions in the next stage.=0A> =0A> Thanks for reading carefully :-)= =0A> =0A> But I don't get your point: This passage describes how a router (= such as LMA) =0A> forwards multicast data to its downstream interfaces acco= rding to its MFIB. The =0A> tunnel interface is seen as an interface that d= oes encapsulation, implicitly or =0A> explicitly, but the interface is not = hidden (it's also used for PMIP unicast). =0A> The use of PMIP tunnels is c= ertainly not a protocol extension. It is actually =0A> the PMIP way to shif= t traffic between LMA & MAG.=0A> =0A> So nothing new here - it's just Inter= net routing.=0A> =0A=0AThe extension is if you consider RFC 4605. I was thi= nking that you have to extend RFC 4605 in order to be able to integrate IGM= P/MLD Proxy into PMIPv6. =0AAs I said before, yes we can :), but let's do a= t the next stage.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From behcetsarikaya@yahoo.com Wed Nov 25 14:21:14 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94CE3A6B96 for ; Wed, 25 Nov 2009 14:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER9nmBzfzipE for ; Wed, 25 Nov 2009 14:21:14 -0800 (PST) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id EDE143A6774 for ; Wed, 25 Nov 2009 14:21:13 -0800 (PST) Received: (qmail 6106 invoked by uid 60001); 25 Nov 2009 22:21:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259187669; bh=W9vDV5BniL1QhyTOHxNYT4kYhdTxD/3Llc+rzPeLFaE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H8iuJTSl4Bgp+BRmyCCX8kwpF3Af4s3F7wq62VoJoY6HWGJnaMOqSXeBtqh5JX25iJmSXyaq6PuJdyy01R7InaIyP9dMSd/4sV8OqIFsMSkSibsYIKzM1CBYNPtt1XsXrR6hLYiDL7llgcWWMPyaAVeKKpJYuAWA9U046uPko2Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w7fjkAyRGObZmZBjW0IpXjO0KP29BAldyBSEye0405XdPzo57Uyavm0cR2BpfF3xI1ZJi5AdYNljDiifHPLM0HmOCDQFKnFjPqVLDIeM7WE+qanuNkJB1rde4YiGbFyKUjDqZl9Halr8rCRbSgMM8MeiZcaFr0wGTibEt2UCipg=; Message-ID: <324591.4871.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: Y5VyQuYVM1mTUf73BWUZlh07HXIG6Qm5VhXdVpQNxkO_xChVy1iuwLwbl2rjcjnTTdWAjOsc_D..MrFn2LpErcYW9t9flzcxI7O.ncnpN7XBBYvpGC6gpc4o0hpXvav3CEIr6l9vfaDI2B0ZUFWQRCLlDGNVpGqg0kJ4.qd6PDgxg9YN9buUVbQBUOsNnah5PlGeH4oEQ.CDw13Sxp87gManJOK8XyWrCocZdgDJPBCz1tSakIPKvoCiUqKsy62D8RoZ332YWyjouTA9ozonEylxkV5MMqJdiIMk1I07WIuB6x1cR8IDULCSPyngTc_ud3qsyUIPkGUsC_rV9Q..Fy9j2kL_M4PnO.dFMhKC Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Wed, 25 Nov 2009 14:21:09 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <18166C82-51AD-440F-97A0-0B493B49E731@gmail.com> Date: Wed, 25 Nov 2009 14:21:09 -0800 (PST) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <18166C82-51AD-440F-97A0-0B493B49E731@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:21:14 -0000 Hi Jouni,=0A=0A=A0=0A=A0 It seems like I became like man with the target in= your slides, everybody is shooting at me :).=0A=0A=A0 See more below.=0A= =0A----- Original Message ----=0A> From: jouni korhonen =0A> To: Behcet Sarikaya =0A> Cc: sijeon79@gmail.co= m; multimob@ietf.org=0A> Sent: Wed, November 25, 2009 3:55:44 PM=0A> Subjec= t: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A> Hi Behcet,=0A> =0A> = =0A> On Nov 24, 2009, at 6:45 PM, Behcet Sarikaya wrote:=0A> =0A> [snip]=0A= > =0A> =0A> >> =0A> >> [behcet] Optimization here is compared with bi-direc= tional tunneling and=0A> >> remote subscription. Clearly MLD Proxy=A0 at th= e MAG integrated with LMA is=0A> >> an optimization because LMA sends one c= opy for the whole group which may=0A> >> have many members.=0A> >> And the = charter says the optimizations are left to rechartering.=0A> >> =0A> >> =3D= > [Seil Jeon] IMHO, I don't think. We need PMIPv6 multicasting solution=0A>= >> not adding PMIPv6 + multicasting.=0A> >>=A0 =A0 When we consider basic = solution for multicasting, we have to find=0A> >> reasonble way as possible= , and it is our job.=0A> >>=A0 =A0 As other folks said, I have no doubt tha= t MLD proxy is simplest=0A> >> possible approach for remote subscription so= lution.=0A> >> =0A> > =0A> > I think we should understand optimizations loo= king at the base solution, the =0A> optimizations are vis-a-vis the base so= lution, we can say that locally available =0A> multicast with all variation= s is an optimization. =0A> > =0A> > Another point is: according to RFC 4605= , MLD Proxy forwards multicast data =0A> downstream or sends aggregate join= s upstream. =0A> > If you read draft-schmidt, =0A> > Based on the multicast= -transparent operations of=0A> >=A0 the MAGs, the LMA experiences its tunne= l interfaces as multicast=0A> >=A0 enabled downstream links, serving zero t= o many listening nodes.=0A> >=A0 Multicast traffic arriving at the LMA is t= ransparently forwarded=0A> >=A0 according to its multicast forwarding infor= mation base.=0A> > tunneling is implicit or has been carefully hidden. Isn'= t this protocol =0A> extension?=0A> > So I am saying that we should look at= these extensions in the next stage.=0A> =0A> The MLD Proxy proposal is ali= gned with RFC5213 way of doing MAG-LMA tunneling. =0A> For non-multicast (u= nicast) traffic there is also one tunnel, which aggregates =0A> traffic for= multiple MNs between the MAG-LMA. The tunnel interfaces are not =0A> "care= fully" hidden in any way, for unicast or multicast traffic. What is needed = =0A> in case of multicast, is having proper route entries pointing to tunne= l =0A> interfaces in both MAG and LMA side, and SPD entries to match proper= type of =0A> traffic. I fail to see this as an protocol extension. Further= more, I don't =0A> understand why we would need to come up with a clearly i= nferior solution when =0A> there is a better one available, which even seem= s to fit into the existing =0A> protocol solution.=0A=0A"inferior"?=0A=0AIt= depends on how you look at it. Even MLD Proxy may be inferior to another b= etter solution yet to be found.=0A=0A"SPD entries"? We're not doing any sec= urity things yet.=0A=0AThat said, let's continue to discuss and explore all= facets, it is going to be productive for sure.=0A=0ARegards,=0A=0ABehcet= =0A=0A=0A From waehlisch@ieee.org Wed Nov 25 14:25:15 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A823A687E for ; Wed, 25 Nov 2009 14:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLS0jkH6hY4V for ; Wed, 25 Nov 2009 14:25:14 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 905AC3A67E7 for ; Wed, 25 Nov 2009 14:25:14 -0800 (PST) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NDQIO-000CPi-Ld; Wed, 25 Nov 2009 23:25:08 +0100 Date: Wed, 25 Nov 2009 23:25:07 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <74406.71791.qm@web111411.mail.gq1.yahoo.com> Message-ID: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:25:15 -0000 Hi Behcet, see inline: On Wed, 25 Nov 2009, Behcet Sarikaya wrote: > > > Another point is: according to RFC 4605, MLD Proxy forwards > > > multicast data downstream or sends aggregate joins upstream. If you > > > read draft-schmidt, > > > > > >Based on the multicast-transparent operations of the MAGs, the LMA > > >experiences its tunnel interfaces as multicast enabled downstream > > >links, serving zero to many listening nodes. Multicast traffic > > >arriving at the LMA is transparently forwarded according to its > > >multicast forwarding information base. > > > tunneling is implicit or has been carefully hidden. Isn't this protocol > > extension? > > > So I am saying that we should look at these extensions in the next stage. > > > > Thanks for reading carefully :-) > > > > But I don't get your point: This passage describes how a router (such > > as LMA) forwards multicast data to its downstream interfaces according > > to its MFIB. The tunnel interface is seen as an interface that does > > encapsulation, implicitly or explicitly, but the interface is not > > hidden (it's also used for PMIP unicast). The use of PMIP tunnels is > > certainly not a protocol extension. It is actually the PMIP way to > > shift traffic between LMA & MAG. > > > > So nothing new here - it's just Internet routing. > > > The extension is if you consider RFC 4605. I was thinking that you have > to extend RFC 4605 in order to be able to integrate IGMP/MLD Proxy into > PMIPv6. As I said before, yes we can :), but let's do at the next stage. > What are you talking about? As Thomas said there is nothing new, especially no extension. Please, say clearly what is the extension in which draft! If it helps, draw a picture. Thanks matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From stig@venaas.com Wed Nov 25 14:33:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45B03A67AE for ; Wed, 25 Nov 2009 14:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRhtRoObKT+A for ; Wed, 25 Nov 2009 14:33:09 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id B84B13A67AA for ; Wed, 25 Nov 2009 14:33:08 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 1403D21E04; Wed, 25 Nov 2009 23:33:01 +0100 (CET) Message-ID: <4B0DB09A.6090408@venaas.com> Date: Wed, 25 Nov 2009 14:32:58 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthias Waehlisch References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:33:10 -0000 Matthias Waehlisch wrote: > Hi Behcet, > > see inline: > > On Wed, 25 Nov 2009, Behcet Sarikaya wrote: > >>>> Another point is: according to RFC 4605, MLD Proxy forwards >>>> multicast data downstream or sends aggregate joins upstream. If you >>>> read draft-schmidt, >>>> >>>> Based on the multicast-transparent operations of the MAGs, the LMA >>>> experiences its tunnel interfaces as multicast enabled downstream >>>> links, serving zero to many listening nodes. Multicast traffic >>>> arriving at the LMA is transparently forwarded according to its >>>> multicast forwarding information base. >>>> tunneling is implicit or has been carefully hidden. Isn't this protocol >>> extension? >>>> So I am saying that we should look at these extensions in the next stage. >>> Thanks for reading carefully :-) >>> >>> But I don't get your point: This passage describes how a router (such >>> as LMA) forwards multicast data to its downstream interfaces according >>> to its MFIB. The tunnel interface is seen as an interface that does >>> encapsulation, implicitly or explicitly, but the interface is not >>> hidden (it's also used for PMIP unicast). The use of PMIP tunnels is >>> certainly not a protocol extension. It is actually the PMIP way to >>> shift traffic between LMA & MAG. >>> >>> So nothing new here - it's just Internet routing. >>> >> The extension is if you consider RFC 4605. I was thinking that you have >> to extend RFC 4605 in order to be able to integrate IGMP/MLD Proxy into >> PMIPv6. As I said before, yes we can :), but let's do at the next stage. Not sure if this helps, but RFC 4605 does not care about the interface types. So whether an interface is a tunnel or not makes no difference wrt 4605. > What are you talking about? As Thomas said there is nothing new, > especially no extension. > > Please, say clearly what is the extension in which draft! If it helps, > draw a picture. > > > Thanks > matthias > From jouni.nospam@gmail.com Thu Nov 26 02:47:29 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6643A686C for ; Thu, 26 Nov 2009 02:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjMSirL-jVaQ for ; Thu, 26 Nov 2009 02:47:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 3C3B23A62C1 for ; Thu, 26 Nov 2009 02:47:28 -0800 (PST) Received: by bwz23 with SMTP id 23so442635bwz.29 for ; Thu, 26 Nov 2009 02:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Tfej41ktHan/Z5FS/KqgsWDRoTXcAWLp5+v7Cn3C4QM=; b=u6AA+jMpnHcZkvvVdVFMqm2xQZh1FST8BRHbBtKJQ7f1RXSp1kfdTU/47GnFOKoEes e2BAz9QJljU9XWox1bGdeHTbsuDAP8a/FWQNoAZRMMak7rNDbADe1Wh+Hvvkv1pVubYv FvWR3+nArBandIdTWrzlT9bmWiCu6W1HV5mfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=O2hPNbKACxYJMyHXiB2jRtJsypBVh6Lqdb6N9q/S5VQ7142VpjEycgzLXYC0A92dcD S6MZ0qpkJTXeu0L10G8PrlwVLf3GorDUUnY0AezIiJcz8qQIu7Bg4c/Tvs9pa2e+8siz XMhKJHChoUeZnEKDrFyJzoE8yYRwQUXPV6nA8= Received: by 10.204.6.24 with SMTP id 24mr243457bkx.25.1259232440299; Thu, 26 Nov 2009 02:47:20 -0800 (PST) Received: from a88-112-205-101.elisa-laajakaista.fi (a88-112-205-101.elisa-laajakaista.fi [88.112.205.101]) by mx.google.com with ESMTPS id 14sm178756fxm.7.2009.11.26.02.47.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 02:47:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <324591.4871.qm@web111401.mail.gq1.yahoo.com> Date: Thu, 26 Nov 2009 12:47:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <18166C82-51AD-440F-97A0-0B493B49E731@gmail.com> <324591.4871.qm@web111401.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1077) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 10:47:29 -0000 Hi Behcet, On Nov 26, 2009, at 12:21 AM, Behcet Sarikaya wrote: > Hi Jouni, >=20 > =20 > It seems like I became like man with the target in your slides, = everybody is shooting at me :). Heh ;) Maybe I need to update the ending slides for the next meeting.. [snip] >>>=20 >>> I think we should understand optimizations looking at the base = solution, the=20 >> optimizations are vis-a-vis the base solution, we can say that = locally available=20 >> multicast with all variations is an optimization.=20 >>>=20 >>> Another point is: according to RFC 4605, MLD Proxy forwards = multicast data=20 >> downstream or sends aggregate joins upstream.=20 >>> If you read draft-schmidt,=20 >>> Based on the multicast-transparent operations of >>> the MAGs, the LMA experiences its tunnel interfaces as multicast >>> enabled downstream links, serving zero to many listening nodes. >>> Multicast traffic arriving at the LMA is transparently forwarded >>> according to its multicast forwarding information base. >>> tunneling is implicit or has been carefully hidden. Isn't this = protocol=20 >> extension? >>> So I am saying that we should look at these extensions in the next = stage. >>=20 >> The MLD Proxy proposal is aligned with RFC5213 way of doing MAG-LMA = tunneling.=20 >> For non-multicast (unicast) traffic there is also one tunnel, which = aggregates=20 >> traffic for multiple MNs between the MAG-LMA. The tunnel interfaces = are not=20 >> "carefully" hidden in any way, for unicast or multicast traffic. What = is needed=20 >> in case of multicast, is having proper route entries pointing to = tunnel=20 >> interfaces in both MAG and LMA side, and SPD entries to match proper = type of=20 >> traffic. I fail to see this as an protocol extension. Furthermore, I = don't=20 >> understand why we would need to come up with a clearly inferior = solution when=20 >> there is a better one available, which even seems to fit into the = existing=20 >> protocol solution. >=20 > "inferior"? >=20 > It depends on how you look at it. Even MLD Proxy may be inferior to = another better solution yet to be found. This is, of course, true.=20 >=20 > "SPD entries"? We're not doing any security things yet. >=20 > That said, let's continue to discuss and explore all facets, it is = going to be productive for sure. Sure. Cheers, Jouni >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 From behcetsarikaya@yahoo.com Mon Nov 30 10:19:38 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AE63A697E for ; Mon, 30 Nov 2009 10:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhgiLSyinGwP for ; Mon, 30 Nov 2009 10:19:37 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 95CEB3A6838 for ; Mon, 30 Nov 2009 10:19:37 -0800 (PST) Received: (qmail 68915 invoked by uid 60001); 30 Nov 2009 18:19:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259605168; bh=Zjwu0aXrjtjDYubk50uut6gnZ72dJY3pxN/Kr3ZPQ08=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mAN14/NjCRJNrYUuSCXl2synszRLQWLKg5DSJRc9+7kx3+LWF1+SL4K0AwIeucbgvz0Puyl/wVJQFNJlFcj3c0CKERtVW1zAFnpCReMrd2uESULcEUYxTrowIGThB3ioVKX/FFHvnLOevA8lAoFkHENfXcois7omufYt1fhb8eM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hON3BkJzWUTZM7k9ip4cgikmfcVTw11qcLjEpJZiVtfqEb8VWLmHHMJAHxraZd+6ReKFzhEC5KKGkV/3U49G/9Aa9WsL4P4Pe6okSheROPO9JFGDRraOK7H9SJB0llyQJBXOObSAwRv+h578rq2xzzNcE61HmrJjUtBCUvNwSjg=; Message-ID: <383491.68900.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: FyEM4kAVM1k5otnn1R1F1HOLsJJA9QgFKQbtuQqM2BvOMkWIHZmx2rIz3N6xl6ALbMAxi4BeSjhWWlMKTayvNx65MeSPA_DW1d5ZFjn2n_LLI3BIIyZWdXrYRvAeG3_mIHsbrew7Dc3CdpwnO8P21PHlxHVVVPOToihiE7wZkBV3gyudvMpG2xE.GdI2TXOH1cBQSVJiHYgbHkHw.gxfBDetDl0LFg_Vnkm9_nLK7PK6cu1vMZRTVn7A3rb924380EaMzBsPyyHesHPO7vHXFTTgn3X8WcwVS.8G9O7NGpZrC44XFQrHoSAelVtAheBtCPVPLMxbIHw6B8T2bfDLiL_7tzisLr9stI8oyxUg53RWepR0ETdbkNemtNEVF5edNq3w9GCH2goH9cIxEJJo2vUENRi85mjfsnzrpjbzG6ycq1GjVaLnjzGgSOgWNZ4Dnmeqb5FbHdn82SPSLbMvusxVXxsmzXyRyYmtBruFBi9b95dkC6skVTdLMBC5pO1sOhuOtAcIr57b3nDKudk23_LeKhkTxfKnwUdc9EH2QQ-- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 30 Nov 2009 10:19:28 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> Date: Mon, 30 Nov 2009 10:19:28 -0800 (PST) From: Behcet Sarikaya To: Matthias Waehlisch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:19:38 -0000 Hello Matthias,=0A=A0 What I'm saying is simple:=0A=0ARFC 4605 defines upst= ream to MLD Proxy as a regular IP interface and same as downstream to MR.= =0A=0AIt is clearly not a link-local interface.=0A=0AIt is also clearly not= a tunneling interface. =0A=0Adraft-schmidt is introducing tunneling on thi= s and this is an extension.=0A=0ADoes RFC 4605 care about tunneling? I don'= t know. If they did they would have mentioned it in the RFC.=0A=0AI hope it= is clear now. Sorry for not making it clear before.=0A=0ARegards,=0A=0ABeh= cet=0A=0A=0A=0A----- Original Message ----=0A> From: Matthias Waehlisch =0A> To: Behcet Sarikaya =0A> Cc: Thoma= s C. Schmidt ; multimob@ietf.org=0A> Sen= t: Wed, November 25, 2009 4:25:07 PM=0A> Subject: Re: [multimob] IGMP/MLD P= roxy at the MAG=0A> =0A> Hi Behcet,=0A> =0A> =A0 see inline:=0A> =0A> On We= d, 25 Nov 2009, Behcet Sarikaya wrote:=0A> =0A> > > > Another point is: acc= ording to RFC 4605, MLD Proxy forwards =0A> > > > multicast data downstream= or sends aggregate joins upstream. If you =0A> > > > read draft-schmidt,= =0A> > > >=0A> > > >Based on the multicast-transparent operations of the MA= Gs, the LMA =0A> > > >experiences its tunnel interfaces as multicast enable= d downstream =0A> > > >links, serving zero to many listening nodes. Multica= st traffic =0A> > > >arriving at the LMA is transparently forwarded accordi= ng to its =0A> > > >multicast forwarding information base.=0A> > > > tunnel= ing is implicit or has been carefully hidden. Isn't this protocol =0A> > > = extension?=0A> > > > So I am saying that we should look at these extensions= in the next stage.=0A> > > =0A> > > Thanks for reading carefully :-)=0A> >= > =0A> > > But I don't get your point: This passage describes how a router= (such =0A> > > as LMA) forwards multicast data to its downstream interface= s according =0A> > > to its MFIB. The tunnel interface is seen as an interf= ace that does =0A> > > encapsulation, implicitly or explicitly, but the int= erface is not =0A> > > hidden (it's also used for PMIP unicast). The use of= PMIP tunnels is =0A> > > certainly not a protocol extension. It is actuall= y the PMIP way to =0A> > > shift traffic between LMA & MAG.=0A> > > =0A> > = > So nothing new here - it's just Internet routing.=0A> > > =0A> > The exte= nsion is if you consider RFC 4605. I was thinking that you have =0A> > to e= xtend RFC 4605 in order to be able to integrate IGMP/MLD Proxy into =0A> > = PMIPv6. As I said before, yes we can :), but let's do at the next stage.=0A= > > =0A> =A0 What are you talking about? As Thomas said there is nothing ne= w, =0A> especially no extension.=0A> =0A> =A0 Please, say clearly what is t= he extension in which draft! If it helps, =0A> draw a picture.=0A> =0A> =0A= > Thanks=0A> =A0 matthias=0A> =0A> -- =0A> Matthias Waehlisch=0A> .=A0 FU B= erlin, Inst. fuer Informatik, AG CST=0A> .=A0 Takustr. 9, D-14195 Berlin, G= ermany=0A> .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~wae= hl=0A> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net= =0A=0A=0A=0A From waehlisch@ieee.org Mon Nov 30 12:57:27 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34B93A679C for ; Mon, 30 Nov 2009 12:57:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMEDgx8mXbky for ; Mon, 30 Nov 2009 12:57:26 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A1D9C28C169 for ; Mon, 30 Nov 2009 12:57:06 -0800 (PST) Envelope-to: multimob@ietf.org Received: from 93-40-137-39.ip39.fastwebnet.it ([93.40.137.39] helo=mw-thinkpad.fastwebnet.it) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFDIn-0009WT-6G; Mon, 30 Nov 2009 21:56:58 +0100 Date: Mon, 30 Nov 2009 21:56:05 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <383491.68900.qm@web111405.mail.gq1.yahoo.com> Message-ID: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:57:28 -0000 Hi Behcet, thanks for clarification! As Stig said: MLD operates transparently w.r.t. the interface type. On Mon, 30 Nov 2009, Behcet Sarikaya wrote: > RFC 4605 defines upstream to MLD Proxy as a regular IP interface and > same as downstream to MR. > No: according to RFC4605, an upstream interface is defined as follows: --snip-- 2.1. Upstream Interface A proxy device's interface in the direction of the root of the tree. Also called the "Host interface". --snap-- You make two mistakes: 1. the direction/perspective of the upstream interface 2. RFC4605 does not make any assumption according to the type of the interface > It is clearly not a link-local interface. > > It is also clearly not a tunneling interface. > In which part of the RFC is this stated? > draft-schmidt is introducing tunneling on this and this is an extension. > First is correct, second is incorrect. > Does RFC 4605 care about tunneling? I don't know. If they did they would > have mentioned it in the RFC. > That's nonsene: You are right, they they did not mention tunneling. But as consequence, they did not care about tunneling. RFC4605 operates transparently to the interface type. > I hope it is clear now. Sorry for not making it clear before. > Thanks again. If I am incorrect, please state appropriate parts of the RFC(s). Thanks matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From behcetsarikaya@yahoo.com Mon Nov 30 13:11:40 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE673A6894 for ; Mon, 30 Nov 2009 13:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjH4-KvwqsFO for ; Mon, 30 Nov 2009 13:11:39 -0800 (PST) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id 60EF928C165 for ; Mon, 30 Nov 2009 13:11:39 -0800 (PST) Received: (qmail 7986 invoked by uid 60001); 30 Nov 2009 21:11:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259615489; bh=7NBXO8qjvZ6gT5v8yvDad4jSSRGauNbx06S+tkaVNCQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1y+GzmTbbx0q+4Sd0Yuyl3xIWqwvtEs2VI42YFwbnK30N1Pms9ZBfGbVniNG3UTajL8lbn1NELWOSCR2ba59r4CDUoJTmtk2E3kOaj3rI68d45g4wOLbzPuMzLItVkKY/PyHjUqNw6tKMnON9ZZVl3w3bXt1l65+MDzEujO4n3k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SBVxb6PWPWI/vREliVh87rS2RhxrAYpWNHZegnT7dt07wJwIZIhDhGF6/hzs/weFaZ72xtgPX2bFTycaeQWOKrZhBIb0gZYCQhuoJyuawncZ55GbCAqhqvrPeVHz1LLCoKDNSik8wPeq/dAiABQKNqrP6suZUgMlMTWx081jqlY=; Message-ID: <32617.6250.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: p923.loVM1mfWxLed6wWIddIo3jiMFwPIf.1Kqd8Rim0_23217U9UWws.RrDoLlXIIwq9PWx3TVSBEewS_opWMv5qj0zgjugit.MEVtKrH5b68v9AwX9MG2gkpQ7E5.Pufgl49TYbazPmALSyz3R6rATCjzaT_4xx5HRnZYaLYbeo0aPLTXpXBA9fmL..8o1rDxQmj4XRnfq_hbg4BsDgMx3m72NE17UxbtkO0TKxLFHO5_9Wge8ADwsBU7t_yo1_5myzVn9FHAAfeiXZs4SuX_GAcvHgb0xe8abCq29jHMJViKWYhsJGar8hpiAHCP.yqFvESsk.FLOd1LZhdditWNPXB_ddWUFNWttoQSA7AR89wJ6bVTyeYwmymVsmiOLbvYmKV6s5j2cVzPjfOs6e6u9ff5YFefCsOiyImR7MFWZlA5ZtNoaKiu2uydgnFkk9A36yNruuBwhh4_KSQR0ysZ_VJfZlE_2dIfBsjMnz1K81X06vBEFUaYS8b6P1yQ9VRlRSk5OBzuihMYp9h3qFXcYt2RKiYwpaheGkRrGpg-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Mon, 30 Nov 2009 13:11:28 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 30 Nov 2009 13:11:28 -0800 (PST) From: Behcet Sarikaya To: Matthias Waehlisch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:11:41 -0000 Hi Matthias,=0A=A0 Is host interface a tunnel interface?=0A=0AMy answer is = no. Tell me if your answer is yes?=0A=0ASo I think this closes the discussi= on.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> Fr= om: Matthias Waehlisch =0A> To: Behcet Sarikaya =0A> Cc: Thomas C. Schmidt ;= multimob@ietf.org=0A> Sent: Mon, November 30, 2009 2:56:05 PM=0A> Subject:= Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A> Hi Behcet,=0A> =0A> =A0 = thanks for clarification!=0A> =0A> =A0 As Stig said: MLD operates transpare= ntly w.r.t. the interface type.=0A> =0A> On Mon, 30 Nov 2009, Behcet Sarika= ya wrote:=0A> =0A> > RFC 4605 defines upstream to MLD Proxy as a regular IP= interface and =0A> > same as downstream to MR.=0A> >=0A> =A0 No: according= to RFC4605, an upstream interface is defined as follows:=0A> =0A> --snip--= =0A> =0A> 2.1.=A0 Upstream Interface=0A> =0A> =A0 A proxy device's interfac= e in the direction of the root of the tree.=0A> =A0 Also called the "Host i= nterface".=0A> =0A> --snap--=0A> =0A> =A0 You make two mistakes:=0A> =0A> = =A0 1. the direction/perspective of the upstream interface=0A> =0A> =A0 2. = RFC4605 does not make any assumption according to the type of the =0A> inte= rface=0A> =0A> =0A> > It is clearly not a link-local interface.=0A> >=0A> >= It is also clearly not a tunneling interface. =0A> >=0A> =A0 In which part= of the RFC is this stated?=0A> =0A> > draft-schmidt is introducing tunneli= ng on this and this is an extension.=0A> >=0A> =A0 First is correct, second= is incorrect.=0A> =0A> > Does RFC 4605 care about tunneling? I don't know.= If they did they would =0A> > have mentioned it in the RFC.=0A> >=0A> =A0 = That's nonsene: You are right, they they did not mention tunneling. But =0A= > as consequence, they did not care about tunneling. RFC4605 operates =0A> = transparently to the interface type.=0A> =0A> > I hope it is clear now. Sor= ry for not making it clear before.=0A> >=0A> =A0 Thanks again.=0A> =0A> =A0= If I am incorrect, please state appropriate parts of the RFC(s).=0A> =0A> = =0A> Thanks=0A> =A0 matthias=0A> =0A> =0A> -- =0A> Matthias Waehlisch=0A> .= =A0 FU Berlin, Inst. fuer Informatik, AG CST=0A> .=A0 Takustr. 9, D-14195 B= erlin, Germany=0A> .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin= .de/~waehl=0A> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-l= ab.net=0A=0A=0A=0A