From mobopts-bounces@irtf.org Mon Oct 6 14:57:55 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17C728C23E; Mon, 6 Oct 2008 14:57:54 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE9C28C23F for ; Mon, 6 Oct 2008 14:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.029 X-Spam-Level: X-Spam-Status: No, score=-100.029 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799, 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 ffRWPwLGeXIJ for ; Mon, 6 Oct 2008 14:57:53 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 98ADA28C233 for ; Mon, 6 Oct 2008 14:57:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thunder2.amsl.com (Postfix) with ESMTP id AEEF748079 for ; Mon, 6 Oct 2008 14:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (thunder2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL9uYUXuTvfn for ; Mon, 6 Oct 2008 14:58:31 -0700 (PDT) Received: from [192.168.1.101] (unknown [173.8.133.94]) by thunder2.amsl.com (Postfix) with ESMTP id 88ED247ED3 for ; Mon, 6 Oct 2008 14:58:31 -0700 (PDT) Message-ID: <48EA8A08.2060403@amsl.com> Date: Mon, 06 Oct 2008 14:58:32 -0700 From: Glen User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mobopts@irtf.org X-Enigmail-Version: 0.95.7 Subject: [Mobopts] IRTF List Move X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Greetings: This email is being sent, at the request of Aaron Falk, to inform you that this IRTF list has now been moved into the irtf.org domain. Previously, you could send to this list either @ietf.org OR @irtf.org, and your mail would go through. That is still the case, although the @irtf.org address is now "more correct." However, mail sent through this list will now come FROM the @irtf.org domain (as it should), and this change may require that you update your mail filters or other settings to correctly recognize this email. If you have any questions, please feel free to contact me. Note that I am NOT a subscriber to this list, so you will need to email Aaron or myself directly if you have questions. Thank you for your patience with this move. Glen Barney IT Director Association Management Solutions IETF/IRTF Secretariat _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Oct 7 16:38:09 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145B93A689F; Tue, 7 Oct 2008 16:38:09 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF803A685A for ; Tue, 7 Oct 2008 16:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 H4YUivx5vmFh for ; Tue, 7 Oct 2008 16:38:07 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id A79A73A6767 for ; Tue, 7 Oct 2008 16:38:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 20C8590015 for ; Tue, 7 Oct 2008 19:38:42 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18797-08 for ; Tue, 7 Oct 2008 19:38:41 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 7 Oct 2008 19:38:41 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 19:38:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 19:42:18 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666046E862A@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266603F6177F@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt Thread-Index: AckR4n6yT4YVrm96TGyp1knIsglYjQW81VGA From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 07 Oct 2008 23:38:41.0534 (UTC) FILETIME=[D48411E0:01C928D5] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0431839089==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0431839089== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C928D5.D4ABDCD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C928D5.D4ABDCD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello folks, =20 The RG LC has expired. We have received a couple of good reviews; I would have liked some more input.=20 Folks can still provide some input for another week (read: at least those with active IDs, please take a look). =20 Authors: could you please reply to the reviews provided, even if you accept all the input? =20 Thanks, =20 -Rajeev =20 =20 ________________________________ From: mobopts-bounces@ietf.org [mailto:mobopts-bounces@ietf.org] On Behalf Of Koodli, Rajeev Sent: Monday, September 08, 2008 11:41 AM To: mobopts@irtf.org Subject: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt =20 =20 Hello folks, =20 This is to initiate a LC for the Multicast Mobility document. =20 This document has already gone through some good reviews resulting in the current version. =20 However, we need broader review from the RG folks, in order to progress this (and other RG) documents. =20 Please provide your comments by September 26.=20 =20 ID URL: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-04 =20 Thanks, =20 -Rajeev =20 =20 ------_=_NextPart_001_01C928D5.D4ABDCD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = folks,

 

The RG LC has expired. We have = received a couple of good reviews; I would have liked some more input. =

Folks can still provide some input = for another week (read: at least those with active IDs, please take a = look).

 

Authors: could you please reply to = the reviews provided, even if you accept all the = input?

 

Thanks,

=

 

-Rajeev

=

 

 

From: mobopts-bounces@ietf.org [mailto:mobopts-bounces@ietf.org] On Behalf Of Koodli, Rajeev
Sent: Monday, September = 08, 2008 11:41 AM
To: mobopts@irtf.org
Subject: [Mobopts] RG = Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt

 

 

Hello folks,

 

This is to initiate a LC for the Multicast Mobility document.

 

This document has already gone through some good = reviews resulting in the current version.

 

However, we need broader review from the RG folks, in = order to progress this (and other RG) documents.

 

Please provide your comments by September 26. =

 

ID URL: htt= p://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-04<= /span>

 

Thanks,

 

-Rajeev

 

 

------_=_NextPart_001_01C928D5.D4ABDCD1-- --===============0431839089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts --===============0431839089==-- From mobopts-bounces@irtf.org Thu Oct 9 15:11:49 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494A73A6969; Thu, 9 Oct 2008 15:11:49 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5433A68D2 for ; Thu, 9 Oct 2008 15:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] 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 mtiBb4P56P4O for ; Thu, 9 Oct 2008 15:11:46 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 989A33A67FD for ; Thu, 9 Oct 2008 15:11:45 -0700 (PDT) Envelope-to: mobopts@irtf.org Received: from e178149029.adsl.alicedsl.de ([85.178.149.29] helo=[192.168.178.20]) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ko3jt-000E20-KR; Fri, 10 Oct 2008 00:12:10 +0200 Message-ID: <48EE819D.1010801@informatik.haw-hamburg.de> Date: Fri, 10 Oct 2008 00:11:41 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Marshall Eubanks References: <4D35478224365146822AE9E3AD4A266603F6177F@exchtewks3.starentnetworks.com> <1133325F-BA85-4FD3-883E-59980E5B2072@multicasttech.com> In-Reply-To: <1133325F-BA85-4FD3-883E-59980E5B2072@multicasttech.com> Cc: mobopts@irtf.org Subject: Re: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Marshall, many thanks for your detailed review ... and sorry for answering late. Please see answers/comments inline. Marshall Eubanks wrote: > = > A general comment : By its title, this is explicitly an IPv6 document, = > but some things that are mentioned > (DVMRP, SAP, BGMP), which I don't think have IPv6 deployment. I assume = > that a little bit of that is ok but have pointed out a few cases where = > it seems unnecessary. > = Yup ... the perspective is to keep the multicast 'world' somehow = comprehensive ... > Comments on the text : > = > NIT : Section 1, paragraph 5, > In addition, real-time > communication such as conversational voice or video places severe > temporal requirement on mobility protocols: > = > s/requirement/requirements/ > = O.K. - changed. > Section 1, paragraph 5, > = > Can you provide a reference for the 100 ms / 50 ms requirements ? Those = > are fairly tight. > = > For example, I believe that there is an ITU requirements document with a = > 300 msec videoconferencing latency requirement, and there is some old = > Bell Labs telephony work, but I don't recall anything listing 100 msec as > a requirement. > = O.K. - I'll seek a reference. 100 ms is about a spoken syllable and the = statement is intended to express an aim. We weakened it in the following = sentence as not to be a strict requirement. > Section 1.1 > = > I did not find the discussion of "Multi-hop network mobility" to be at = > all clear. A reference would help. > I also did not find the figure 1 to be clear - only the Multi-Hop has a = > Mobile Network in it, which is not > clearly defined. > = > Is Multi-hop network mobility just the same as NEMO ? Then say so, and = > reference it. > = Mobile multi-hop networks coins the class of scenarios, where routing = entities are mobile. NEMO is one solution of those, we cited an overview = article (ref. 8) to hint to a general description of such scenarios and = related issues. As said in 1.1., this is not the focus of the document. Actually, adding = this side remark follows a suggestion of Kevin, who proposed to just = mark the additional problems inherited by mobile networks. The graph is supposed to visualize the additional mobile network, which = you saw - mhmm, what is unclear? > Section 2.1 > = > I would remove this sentence, which is not relevant for IPv6 or this I-D : > = > Other > multicast routing protocols without significant current deployment > include CBT [18], BGMP [19]. > = O.K. This was just for the sake of completeness. > Page 5, paragraph 3 > = > Multicast routing dynamically adapts to the topology of the sender(s) > and receiver(s) participating in a multicast session, which then may > change under mobility. > = > I would change this to > = > Multicast routing dynamically adapts to the network topology at the = > locations of the sender(s) > and receiver(s) participating in a multicast session, which then may > = O.K., done. > Here > = > However, depending on the topology and the > protocol in use, current multicast routing protocols may require a > time close to seconds, or even minutes, to converge following a > change in receiver or sender location. > = > What current multicast protocols would take minutes to converge ? > = :-) o.k., you got us with the "current": DVMRP does, but you don't = consider it current. PIM-SM does, when you move/rebuild the RP, but I = guess this is not the common scenario. I take the minutes out, o.k.? > Page 6, partial paragraph at top > = > Due to statelessness, the bi- > casting of multicast flows does not cause foreseeable degradations at > the transport layer. > = > What does this mean ? Is this a reference to BiDir (if so, say so). > = > By statelessness, do you mean soft-state ? > = No, this is a transport statement, not related to routing states or = BiDir PIM. Bicasting may degrade stateful transport endpoints (in TCP, = SCTP or DCCP), which is not an issue with multicast. > What are foreseeable degradations ? Does it cause unforeseeable = > degradations ? > = What is meant: There still could be issues, e.g., with applications = which don't like bicasting (that sort UDP packets in a careless manner) = ... but this we don't know. What about adding a clarifying remark? > Section 2.2.1 : > = > The problem of achieving seamless multicast listener handovers is > thus threefold: > o Ensure multicast reception, even in visited networks, without > appropriate multicast support. > o Minimize multicast forwarding delay to provide seamless > and fast handovers for real-time services. Dependant on layer 2 > and 3 handover performance, the time available for multicast > mobility operations is typically bound to a fraction of 100 ms. > = > Are you saying that this should be a goal ? Where does that number come = > from ? Be more explicit. > = Mobile multicast protocols come into operation after a layer 2 handoff = and typically after *MIPv6 protocols have completed (a new IPv6 = connectivity is operational). This takes an amount of time (not = explicitly known), which is not negligible (802.11 handoff is between = ~30 and ~300 ms, 3GPP/UMTS is much faster). So we don't know any general = value, but the time for multicast to regain stream connectivity is = actually reduced by these effects. What about: "... is typically bound to the fraction of the total = handover time left after IPv6 connectivity is regained. In real-time = scenarios this may be significantly less than 100 ms." > Section 2.3.1. [end] : > = > In the presence of an > embedded rendezvous point address [26], e.g., the primary rendezvous > point for inter-domain PIM-SM will be globally appointed and the > signaling requirements obsolete. > = > Is this saying that for Embedded RP the RP will always be used, even if = > that leads to triangular routing ? > Isn't such specifications not part a problem statement ? > = > If not, why won't there be a need for signaling ? This section is about source mobility and wants to say that a newly = attached source can immediately contact the RP (like a new source) and = transmit data in the PIM register tunnel. You are pointing to the PIM-SM source-specific shortcuts, which indeed = need to be re-established after a source movement. The latter of course = needs signaling. We will clarify this. > = > Section 2.3.2 : > = > NIT : As the > principle multicast decoupling of a sender from its receivers holds > = > s/principle/principle of/ > = O.K., fixed. > Section 4.1 : > = > Several aspects need consideration: First, dissimilar network access > radio technologies cause distinct group traffic transmissions. There > are: > = > o connection-less link services of a broadcast type, which mostly > are bound to limited reliability; > = > o connection-oriented link services of a point-to-multipoint type, > which require more complex control and frequently exhibit reduced > efficiency; > = > o connection-oriented link services of a broadcast type, which are > restricted to unidirectional data transmission. > = > Which of these choices is used for normal unicast traffic ? One option = > at the wireless link layer in, for example, 3GPP MBMS, is to send = > multicasts are point to point unicast, that also needs to be pointed out = > and its > network access RF implications listed. > = Normal unicast modes are not explicitly listed here ... but we can add = this in the memory of MBMS ;) > Also, a fundamental difference between unicast and multicast in some RF = > technologies is that the unicast transmit power is adjusted to be as = > small as possible based on link layer feedback from the receiver. In = > multicast this is not done, or is done in some cases (e.g., 3GPP MBMS). = > This is why there is a "multicast tax" which means that multicast is not = > as efficient as unicast, unless the group size on the local RF link is > = > some number, typically 2. > = Great point: we will add this. > Section 4.2.1 : > = > To limit or prevent the latter, many vendors have implemented a > configurable rate limit for forwarding multicast packets. > Additionally, an IGMP/MLD snooping or proxy may be active at the > bridging layer between the BSS and the ESS or at switches > interconnecting access points. > = > Is anyone doing the IGMP/MLD snooping or proxy at the RF Layer, to = > prevent the unnecessary RF broadcasting of multicasts by an access point ? > = IGMP/MLD snooping and separation happens at the MAC layer. 802.11 APs do = this at the BSS/ESS bridge (between cable and air), but cannot do at the = wireless PHY. This is different in e.g., 802.16. > Section 4.2.2 : > = > Service flows may provide an optional Automatic > Repeat Request (ARQ) to improve reliability and may operate in point- > to-point or point-to-multipoint (restricted to downlink and without > ARQ) mode. > = > What about mesh mode ? Can't that do multicast ? > = I believe it cannot, because neighboring nodes initiate connections in a = 3-way handshake. But we'll check back with Rajeev, he should reliably know. > = > To invoke a multipoint data channel, the base station assigns a > common CID to all Subscriber Stations in the group. An IPv6 multicast > address mapping to these 16 bit IDs is proposed by copying either the > 4 lowest bits, while sustaining the scope field, or by utilizing the > 8 lowest bits derived from Multicast on Ethernet CS [44]. For > selecting group members, a Base Station may implement IGMP/MLD > snooping or proxy as foreseen in 802.16e-2005 [45]. > = > I did not find that to be at all clear, but to be frank I find = > draft-sekim-802-16-multicast-01 fairly confusing > as well. It might be best not to try and explain it, and just reference = > draft-sekim-802-16-multicast-01. O.k., we'll try to move this somehow to a non-confusing but = comprehensive state. > = > Paragraph 4 : > = > On reception, a Subscriber Station > cannot distinguish multicast from unicast streams. > = > Do you mean, at link layer ? Surely this is not true at the IP layer. > = Yes, of course on the link-layer: now clearly added. > Section 4.2.3 3GPP > = > In 3GPP2 MBMS is called Broadcast and Multicast Service (BCMCS). They = > are very similar - I would mention that somewhere. > = O.k. > In both 3GPP and 3GPP2 multicasts can either be sent using PTP (point to = > point) or PTM (point to multipoint) tunnels, and there is support for, = > e.g., switching from PTP to PTM. > = > P2P uses receiver feedback to adjust power levels. > = > MBMS PTM uses a unidirectional common channel, operating in = > =93Unacknowledged=94 mode, with > = > No adjustment of power levels. > No reporting of lost packets. > = > This means that transmission levels must be conservative, =93worst-case,= =94 = > and thus wasteful of power on average. > = > To help reduce this performance loss, WCMDA supports Packet Downlink = > Ack/Nack Mode (PDAN), where MBMS session feedback can be provided by up = > to 16 terminals in a given cell. I don't know how commonly used this is. > = > I would include some discussion of these issues. > O.K., thanks: we'll do. > Section 4.3 > = > A mobile multicast node may operate homogeneous (horizontal) or > heterogeneous (vertical) layer 2 handovers with or without layer 3 > network changes. Consequently, a dedicated context transfer of > multicast configuration is required at network access. Media > Independent Handover (MIH) is addressed in IEEE 802.21 [53], but is > relevant also beyond IEEE protocols. Mobility services transport for > MIH naturally reside on the network layer and are currently in the > process of specification [54]. > = > = > I did not find this to be clear. Do you need to distinguish between = > horizontal and vertical layer 2 handovers ? > If so, put in a sentence describing this better and / or a reference. > = I guess, this is somehow important to bring to mind: * If you do a vertical handover, you may need to transfer and = *transform* multicast service context (address mapping schemes ...). * If you do a horizontal handover, you still may need to = transfer/activate multicast groups. In many discussions we've experienced people not being aware of that. = We'll try to add clarifications. > Section 5.2.1 : > = > An approach based on dynamically negotiated inter-agent handovers is > presented in [62]. Aside from IETF work, countless publications > present proposals for seamless multicast listener mobility, e.g. [63] > provides a comprehensive overview. > = > I would change "countless" to "numerous" > = O.K., done. > I would point out that reference 63 is 4 years old, fairly old for this = > technology. > = O.K., done. I haven't seen any newer survey though. > Section 5.3.1. : > = > NIT : Solutions for multicast source mobility can be divided in to three > categories: > = > s/in to/into/ > = O.K., is corrected. > o Tree Modification Schemes. In the case of DVMRP routing, > Chang and Yen [71] propose an algorithm to extend the root of a > given delivery tree for incorporating a new source location in > ASM. The authors rely on a complex additional signaling protocol > to fix DVMRP forwarding states and heal failures in the reverse > path forwarding (RPF) checks. > = > Is there a DVMRP for IPv6 ? Is this paragraph needed ? > = It is not for IPv6, but is one of the 'original' attempts. We find it = worth mentioning to hint on the ideas, in case other people might want = to pick up some of it for IPv6. > Section 5.3.2 : > = > The shared tree approach of [69] has been extended to support SSM > mobility by introducing the HoA address record to the Mobility-aware > Rendezvous Points. The MRPs operate using extended multicast routing > tables that simultaneously hold the HoA and CoA and thus can > logically identify the appropriate distribution tree. Mobility thus > re-introduces the concept of rendezvous points to SSM routing. > = > I do not regard that last sentence as by any means having passed IETF = > consensus. > = > How about > = > Mobility thus may > re-introduce the concept of rendezvous points to SSM routing. > = :-) This is only reporting on the work, not a statement meant to reach a = general consensus. It is changed now. Thanks again for the many good pointers! Thomas -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Oct 14 14:09:48 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6C83A6C03; Tue, 14 Oct 2008 14:09:48 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAA43A6C03 for ; Tue, 14 Oct 2008 14:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr9-HEYmEEbH for ; Tue, 14 Oct 2008 14:09:47 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 0A26A3A6B2C for ; Tue, 14 Oct 2008 14:09:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 064DB90013 for ; Tue, 14 Oct 2008 17:10:20 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06666-05 for ; Tue, 14 Oct 2008 17:10:19 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 14 Oct 2008 17:10:19 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 17:10:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 17:14:08 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660485C01D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting in Minneapolis Thread-Index: AckuQcuneiHIDiaYQ/Sadez5jQpJkg== From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 14 Oct 2008 21:10:19.0504 (UTC) FILETIME=[43625700:01C92E41] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Mobopts] Meeting in Minneapolis X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630820490==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --===============0630820490== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92E41.43913965" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92E41.43913965 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello folks, =20 I am debating whether we need to meet officially, given that we have 3 documents in LC and are being revised. I think we can handle the comments on the ML. Comments? =20 Regards, =20 -Rajeev =20 Ps: I have requested a slot anyway. =20 ------_=_NextPart_001_01C92E41.43913965 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello folks,

 

I am debating whether we need to meet officially, = given that we have 3 documents in LC and are being = revised.

I think we can handle the comments on the ML. = Comments?

 

Regards,

 

-Rajeev

 

Ps: I have requested a slot = anyway.

 

------_=_NextPart_001_01C92E41.43913965-- --===============0630820490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts --===============0630820490==--