From mobopts-bounces@irtf.org Fri Dec 02 13:09:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFLb-0006pb-Py; Fri, 02 Dec 2005 13:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFLZ-0006hR-08 for mobopts@megatron.ietf.org; Fri, 02 Dec 2005 13:09:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26331 for ; Fri, 2 Dec 2005 13:08:37 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiFgH-0000iP-D7 for mobopts@irtf.org; Fri, 02 Dec 2005 13:30:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB2HYc220747 for ; Fri, 2 Dec 2005 09:34:38 -0800 X-mProtect: <200512021734> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14186.americas.nokia.com (172.18.141.86, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdWc3d8j; Fri, 02 Dec 2005 09:34:36 PST Message-ID: <43908DBC.6030104@iprg.nokia.com> Date: Fri, 02 Dec 2005 10:09:00 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Mobopts] Vancouver presentations X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hello folks, they are at http://people.nokia.net/~rajeev/mobopts/MobOpts-Vancouver.zip The meeting minutes are not there yet. I hope Telemaco will post them soon to the list. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Dec 08 21:15:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXnJ-0007km-UL; Thu, 08 Dec 2005 21:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXnI-0007bh-Hq for mobopts@megatron.ietf.org; Thu, 08 Dec 2005 21:15:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21577 for ; Thu, 8 Dec 2005 21:14:33 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkXnI-0006nj-8f for mobopts@irtf.org; Thu, 08 Dec 2005 21:15:33 -0500 Received: from wall11.toshiba.co.jp ([133.199.90.149]) by inet-tsb.toshiba.co.jp with ESMTP id jB92FMbf000526 for ; Fri, 9 Dec 2005 11:15:22 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id jB92FlZX007175 for mobopts@irtf.org; Fri, 9 Dec 2005 11:15:47 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id MAA07173; Fri, 9 Dec 2005 11:15:47 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id jB92FLjR023717 for ; Fri, 9 Dec 2005 11:15:21 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id jB92FL7G018863; Fri, 9 Dec 2005 11:15:21 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0IR700GF8KXCQF50@mail.po.toshiba.co.jp> for mobopts@irtf.org; Fri, 09 Dec 2005 11:15:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.60) (envelope-from ) id 1EkXm4-0000eh-FR for mobopts@irtf.org; Thu, 08 Dec 2005 18:14:16 -0800 Date: Thu, 08 Dec 2005 21:14:16 -0500 From: Yoshihiro Ohba To: mobopts@irtf.org Message-id: <20051209021416.GF2410@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.11 X-Spam-Score: 2.4 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mobopts] preauth mailing list X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, A new maling list (preauth@opendiameter.org) has been created to discuss issues related to pre-authentication and heterogeneous handover. To subscribe, please visit the following URL: http://www.opendiameter.org/mailman/listinfo/preauth Best regards, Yoshihiro Ohba _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 12 05:44:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EllAT-0005IE-CD; Mon, 12 Dec 2005 05:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EllAR-0005FE-9g for mobopts@megatron.ietf.org; Mon, 12 Dec 2005 05:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02033 for ; Mon, 12 Dec 2005 05:43:27 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EllB5-0006Vk-DU for mobopts@irtf.org; Mon, 12 Dec 2005 05:45:13 -0500 Received: from [141.22.17.128] (helo=[141.22.17.128]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Ell9y-000CwU-9V; Mon, 12 Dec 2005 11:43:58 +0100 Message-ID: <439D5507.6090705@fhtw-berlin.de> Date: Mon, 12 Dec 2005 11:46:31 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <4374ED41.60506@fhtw-berlin.de> <4391E6DA.2010300@fhtw-berlin.de> <20051208114105.GC9534@tyholt.uninett.no> <43982331.5050303@fhtw-berlin.de> <20051211215653.GC10279@tyholt.uninett.no> In-Reply-To: <20051211215653.GC10279@tyholt.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: Matthias Waehlisch , mobopts Subject: [Mobopts] Re: Review of Draft draft-schmidt-mobopts-mmcastv6-ps-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Stig, many thanks for overlooking the ps-draft. Please see our comments inline: Stig Venaas wrote: > > I've looked at the presentation and think it's good, although some > minor things that was not clear. I think perhaps better to discuss > the draft though. I think the draft is good, but it could be improved > in some places. Below are my thoughts upon reading the draft. Note > that the language could be improved in some places too, but not > commenting on that now. > > Under 2.1 you say > > Multicast sources in general operate decoupled from their receivers > in the following sense: A multicast source submits data to a group of > unknown receivers, thus operating without any feedback channel. It > neither has means to inquire on properties of its delivery trees, nor > will it be able to learn about the state of its receivers. In the > > I suppose this is fine, since this is the general situation. But you > could perhaps note that many multicast applications use RTP where RTCP > is often used for feedback. Well, not sure if worth mentioning. > That's true, one can use RTCP or RTP MIB to monitor multicast sessions. The problem is, though, that we cannot presuppose applications using RTP. There will always possibly be multicast groups not using RTP. One could probably mention RTP in an Appendix ... > For SSM there has also been a proposal for a mechanism called MSNIP > (I can point to draft) that allows a source to know whether there are > receivers (note that it only says receivers or not, not how many or > their identity/addresses). This is probably not so useful then. > Yes, MSNIP was meant to inquire a designated router on the presence of receivers. But as far as I know work on MSNIP has been terminated more than a year ago ... there has been some discussion on ssm mailing list a couple weeks ago wether to revitalise MSNIP - but most people were negative about it. Nevertheless, MSNIP won't tell more about the status of receivers ... and should be rather slow, as well. > In 2.3.1 you say: > > A node submitting data to an ASM group defines the root of either a > shared or source specific delivery tree. Beside root location > > This is not really true. The shared tree is always rooted at the RP. > I know what you mean of course... When forwarding takes care on the > shared tree, the RP receives data natively (by having built a source > specific tree rooted at source) or via PIM registers. So I think this > should be reformulated. > This seems to be a matter of formulation: The statement has been done openly on purpose to include Mcast routing protocols other than PIM-SM. We will change it to be more explicit. > One perhaps interesting thing to consider, is that for IPv6 you may > use embedded-RP (IMO the only way to do inter-domain ASM). For some > type of applications, in particulay the single-source one, the RP > used with embedded-RP should be close to the source, and may in > many cases be the HA. So it might be interesting to consider whether > that may help in any way. Of course in general for ASM, there are > many sources and at least for IPv6, they may not be in the same > domain as the RP. > We agree, one should deepen this discussion. We only offered it a side remark. In the case of single source identifying RP and HA is an idea that has been partly discussed by Rhomdhani. It simplifies a lot. However, in the case of mobility it can neither be assumed nor guaranteed that HA is (resp. remains) close to the Mobile Node/Source. > At the end of 2.3.1 you say: > > In presence of inter- domain multicast routing a change of address > must trigger the exchange of a new multicast source record. > > What are you trying to say here? I'm sort of guessing it might be > something like MSDP Source Active messages. I would say that for > IPv6 there is nothing special about crossing domains, apart from > scoping. For IPv4 the situation is very different. > Yes, this was a reference to MSDP Source Active messages. But you are right, this only applies to IPv4 ... > Another possible ASM issue perhaps, is that application may need to > distinguish between moving source and new source? Although if the > application always sees the sources HoA (and not CoA) as the source > of the multicast packets, this should be ok. If I understand MIPv6 > correctly, it should always only see HoA, or? > This is one of the key features of MIPv6 - mobility is application transparent by passing HoA to the transport layer. RFC 3775 does briefly mention multicast mobility and withstands from applying Binding Caches/Mobility Option Headers to it. But as multicast applications usually are source address aware, it is IMO one key issue to be changed in order to acchieve seamless multicast mobility. > 2.3.2 > > I started to wonder how SSM source filters should work. If it is > the case that the application only sees the HoA in the API, e.g. > as source of multicast packets, then it is reasonable that it > joins the HoA. This means that the address that should be matched > against the source filter is the HoA, not the CoA (which is the > source address in header of the multicast packets). However, > applications should IMO also be able to join a CoA, i.e. using > source filter with the CoA, but if the HoA is used for checking > against the source filter, that will fail. So it seems that a > packet should pass through the source filter if either HoA or > CoA matches. I'm surprised if source filter implementations on > operating systems today do this. > Not sure what you mean: Any application can of course subscribe to CoA (in case it is known) and HoA, as well. The trouble is, that CoA changes under mobility... A typical approach could be to have the MIP stack translate: the application joins to a HoA and the stack identifies current CoA for that HoA (from binding cache or external inquiry) and does the subscription and source filtering w.r.t CoA. However, there are open issues remaining on how to operate handovers. > In solutions you say: > > o Remote Subscription forces the mobile node to re-initiate > multicast distribution subsequent to handover, using its current > Care-of Address. This approach of tree discontinuation relies on > > You are trying to say that the mobile node will re-join the multi- > cast groups through the network it's currently visiting? It's not > really correct to say that it uses it's CoA. No address is used > for joining a group, apart from the link-local address for MLD > reports. > No, this is a misunderstanding: the statement was about sources and the source address in use. It was not about clients - but you're right: we should distinguish and state that more clearly. > In security considerations you say something about binding update > for multicast. I'm not sure what you mean by that and what the > security problems are. > In MIPv6 a binding cache contains the mappings between HoA and current CoA. Tampering with the binding cache is a straight forward way to distroy/hijack/modify sessions. These aspects partly extrapolate to multicast. thomas _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 12 06:21:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elljp-000406-0b; Mon, 12 Dec 2005 06:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elljn-000401-Cz for mobopts@megatron.ietf.org; Mon, 12 Dec 2005 06:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06162 for ; Mon, 12 Dec 2005 06:20:03 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EllkZ-0007lD-0L for mobopts@irtf.org; Mon, 12 Dec 2005 06:21:48 -0500 Received: from [141.22.17.128] (helo=[141.22.17.128]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Elljk-000JiN-O1; Mon, 12 Dec 2005 12:20:56 +0100 Message-ID: <439D5DB2.5000806@fhtw-berlin.de> Date: Mon, 12 Dec 2005 12:23:30 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <4374ED41.60506@fhtw-berlin.de> <4391E6DA.2010300@fhtw-berlin.de> <20051208114105.GC9534@tyholt.uninett.no> <43982331.5050303@fhtw-berlin.de> <20051211215653.GC10279@tyholt.uninett.no> <439D5507.6090705@fhtw-berlin.de> <20051212111012.GC29311@tyholt.uninett.no> In-Reply-To: <20051212111012.GC29311@tyholt.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Matthias Waehlisch , mobopts Subject: [Mobopts] Re: Review of Draft draft-schmidt-mobopts-mmcastv6-ps-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Stig Venaas wrote: > > One thing I didn't mention though. You say that establishing the > multicast forwarding trees may take 30s and more. I would say that > with PIM it should be down to a couple of seconds unless there are > broken implementations or packet loss. Note that some work is going > on to make PIM joins/prunes reliable, which might help regarding > loss. Even a few seconds is too long though, and in rare cases it > might take longer. So I agree we need a solution for mobility. > PIM-SM usually is much faster, provided the shared distribution tree routed at the RP is established, yes. For initial communication/ continuation it's merely given by the distance MSource to RP. The statement was once again an attempt to remain neutral w.r.t. multicast routing protocols. thomas _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 12 10:15:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElpOl-0005c4-9v; Mon, 12 Dec 2005 10:15:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElpOj-0005bt-Mw for mobopts@megatron.ietf.org; Mon, 12 Dec 2005 10:15:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04307 for ; Mon, 12 Dec 2005 10:14:33 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElpPX-0007rq-4N for mobopts@irtf.org; Mon, 12 Dec 2005 10:16:20 -0500 Received: from [141.22.17.128] (helo=[141.22.17.128]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1ElpOd-0008Ft-OB; Mon, 12 Dec 2005 16:15:23 +0100 Message-ID: <439D94A5.1000507@fhtw-berlin.de> Date: Mon, 12 Dec 2005 16:17:57 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger References: <4395E29E.5010707@informatik.haw-hamburg.de> <4396BD19.10006@fokus.fraunhofer.de> <4396C119.5050607@informatik.haw-hamburg.de> <4396C1C9.1010405@fokus.fraunhofer.de> <43980CBD.5090902@informatik.haw-hamburg.de> <43996C9B.1050102@fokus.fraunhofer.de> In-Reply-To: <43996C9B.1050102@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Matthias Waehlisch , mobopts Subject: [Mobopts] Re: Review of Draft draft-schmidt-mobopts-mmcastv6-ps-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Dear Christophe, many thanks for your review - please find comments inline: Christophe Jelger wrote: > I quickly read your draft and here are a few comments. First since I > don't know what the "purpose" of the draft is, I would say it's a fair > introduction of the problem. > This is the purpose of a problem statement - it is meant to exhaustively sketch the problem space and give clues on common approaches to solution. > To be very honest, the content is pretty close to the quite old but > still valid "Xylomenos" paper (IEEE Mag, Jan 1997) which basically well > summarized the issues of mobility with multicast communications. Mhmm - the Xylomenos paper could neither know of MIPv6 nor account for SSM. But you're right, we will add it to the reference list. > Thus I > would also try to extend the current document with a more in-depth > discussion of technical and deployment-related issues. > I'm not sure what you mean by technical ... but there are of course deployment related issues: > For example, I personaly think that multicast routing protocols should > not be changed (i.e. should remain mobility agnostic) and mobility > should be handled at the "edges" (as for Mobile IP). The point here is > that current multicast deployment is already quite limited and complex > (inter-domain) so injecting more complexity is probably not a good idea > (TMHO) and might increase "human resistance" against large-scale > deployment of multicast. This is definitely true and supposedly there is an unspoken demand for ease & simplicity in IETF work anyway ... ... however, the trouble with mobile SSM seems the lack of any such simple, mobility agnostic scheme. At least it is our believe that mobility awareness of routers is a core issue of the SSM problem. > Some details: > - page 4 (top), "multicast communication is asymmetric ..." -> usually > assymetry in multicast rather refers to the router/node different > behaviors (as in MLD) than the sender/receiver roles OK - this is a language fix. > - same page bottom: I haven't followed this recently, but MSNIP can be > used by a source to know whether they are receivers or not > MSNIP was intended to inquire on receivers of designated routers, which is only limited information. However, MSNIP has been terminated a while ago and people didn't want to revitalise it recently. Best regards thomas _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts