From schmidt@informatik.haw-hamburg.de Tue Oct 1 02:45:02 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01A221F8F6D for ; Tue, 1 Oct 2013 02:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQSFS24iQ7e3 for ; Tue, 1 Oct 2013 02:44:57 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 011BF21F8F4A for ; Tue, 1 Oct 2013 02:44:56 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.167] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1VQwVj-000JhH-Ty; Tue, 01 Oct 2013 11:44:56 +0200 Message-ID: <524A9995.4030803@informatik.haw-hamburg.de> Date: Tue, 01 Oct 2013 11:44:53 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <201309251549114085692@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 09:45:02 -0000 Hi Georgios, many thanks! I'll be back on this document shortly, and will provide detailed feedback then. Best regards, Thomas On 01.10.2013 08:06, karagian@cs.utwente.nl wrote: > Hi Thomas, > > During the last multimob WG meeting in Berlin I had volunteerd to > provide comments on the last version of this draft. > > Here are these comments: > > Comment_1:The draft is useful since it is providing a solution for > seamless and fast handover for multicast applications by extending > existing seamless and fast handover solutions used for unicast > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 > (PFMIPv6) specified in RFC5949. > > Comment_2: A motivation section is missing from the draft. In my opinion > it is very useful to include such section in this draft. In particular, > this draft mentions that a seamless and fast handover solutions is > needed for multicast applications like IPTV. Other scenarios and > applications that will make use of such a solutions are Public > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast > communications need to be supported between members of rescue teams, > police officers, fire brigade teams, paramedic teams, command control > offices in order to support the protection and health of citizens. > > In particular three main PPDR scenarios & application types could be > distinguished: > > 1)City security scenario:that can be used to support the day to day > safety and security of citizens. > > 2)Disaster recovery scenario that deals with the protection of people > and rescue teams during large scale natural or man-made disasters, like > flooding, earth quakes and nuclear disasters. > > 3)Temporary Protection PPDR scenario that deals with safety and security > of citizens visiting large planned events like football matches, pop > concerts and protest demonstrations. > > Comment_3: List the requirements that need to be satisfied by this > solution. You may use as example Section 1.1 of > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > > Comment_4: Provide a more detailed message flow description, similar to > the one that is given in Section 5.1.2 in$B!^(B > > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > > This comment holds for Figures 2, 3, 4, 5 > > Comment_5: There is no description on how this draft, which specifies a > mobile multicast listener support solution, can be used in combination a > the mobile multicast senders, solution e.g., > http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt. > > There are scenarios and applications that require the use of these two > solutions simultaneously. > > Best regards, > > Georgios > >> >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multicast Mobility Working Group of the IETF. >> >> Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers >> Author(s) : Thomas C. Schmidt >> Matthias Waehlisch >> Rajeev Koodli >> Godred Fairhurst >> Dapeng Liu >> Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt >> Pages : 27 >> Date : 2013-02-25 >> >>Abstract: >> Fast handover protocols for MIPv6 and PMIPv6 define mobility >> management procedures that support unicast communication at reduced >> handover latency. Fast handover base operations do not affect >> multicast communication, and hence do not accelerate handover >> management for native multicast listeners. Many multicast >> applications like IPTV or conferencing, though, are comprised of >> delay-sensitive real-time traffic and will benefit from fast handover >> execution. This document specifies extension of the Mobile IPv6 Fast >> Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 >> (PFMIPv6) protocols to include multicast traffic management in fast >> handover operations. This multicast support is provided first at the >> control plane by a management of rapid context transfer between >> access routers, second at the data plane by an optional fast traffic >> forwarding that may include buffering. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>multimob mailing list >>multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob > > = = = = = = = = = = = = = = = = = = = = > > > $B!!!!!!!!!!!!!!!!CW(B > $BNi!*(B > > > Shuai Gao > Associate Professor > National Engineering Lab for Next Generation Internet Interconnection > Devices > Beijing Jiaotong University > Beijing, China, 100044 > gaoxlh@gmail.com > 2013-09-25 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany $B!k(B $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 $B!k(B From stig@venaas.com Tue Oct 1 10:15:17 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE9611E8153 for ; Tue, 1 Oct 2013 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3d-+9qBz3Bz for ; Tue, 1 Oct 2013 10:15:14 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 92C9011E81B9 for ; Tue, 1 Oct 2013 10:15:10 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 0BD3C7FD4; Tue, 1 Oct 2013 19:15:04 +0200 (CEST) Message-ID: <524B0301.8080301@venaas.com> Date: Tue, 01 Oct 2013 10:14:41 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com> <5249E105.8040405@informatik.haw-hamburg.de> In-Reply-To: <5249E105.8040405@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:15:17 -0000 Hi On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote: > Hi Stig, > > you're the PIM expert ... however, your statements confuse me. > > Event though the discussion does not matter to the source draft, I would > like to clarify. Please see inline. > > On 30.09.2013 21:19, Stig Venaas wrote: >> Hi >> >> On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote: >>> Dear Cong Liu, >>> >>> thanks for your feedback - please see inline. >>> >>> On 30.09.2013 08:47, Cong Liu wrote: >>> >>>> Regarding this draft, I have the following comments for consideration. >>>> >>>> P14: "This tree can be of lesser routing efficiency than the PIM source >>>> register tunnel established in phase one, but provides the advantage of >>>> immediate data delivery to receivers that share a MAG with S." >>>> - This sentence implicitly indicates that local receivers sharing a MAG >>>> with S cannot receive immediate multicast traffic from the S in phase >>>> one. In my opinion, even in phase one, the MAG acting as the DR has the >>>> related multicast state so that immediate data delivery is possible. If >>>> so, the sentence here is not appropriate. >>>> >>> >>> This sentence actually refers to the building of an (S,G)-Tree at the >>> end of PIM phase II. This tree follows reverse unicast routes and thus >>> traverses the LMA-MAG tunnel - this is why it may be of lower efficiency >>> than the forward (register) tunnel in phase I. >>> >>> What you are referring to is the question of source-local traffic >>> distribution in PIM phase I. According to the way I understand PIM-SM, >>> it does not distribute source-specific traffic locally in Phase I. This >>> is because a local source S generates an (S,G)-State at the sender's >>> local router (DR), but a receiver in ASM requires an (*,G) service. >> >> Traffic is distributed locally independent of the registration process. >> I assume you're talking about a source on one interface, and receivers >> on other interfaces on the same router? In that case for ASM (receivers >> joining a group, not specific sources), there would already be >> (*,G)-join state, and packets from the source would both be forwarded >> on the joined interfaces and sent as PIM registers. >> > > Mhmm ... this would mean that you have two feeds into the distribution > tree: One rooted at the source (valid for local receivers), and one > rooted at the RP - at this stage, we are still in phase I. If you're receiving packets from the source you're already on the SPT and prune the source from the shared tree. >>> If (S,G) traffic were distributed locally, then the required (*,G)-Join >>> to the RP would cause duplicate (S,G) traffic arriving at the >>> source-local receiver. >> >> No, that shouldn't happen. >> > > How do you exclude? In phase I, all traffic is tunneled to the RP and > the "path" from source to RP is not visible to the multicast > distribution system. The DR of the receiver, which happens to be the DR > of one of the sources, would just initiate an (*,G) join towards the RP > ... and all traffic tunneled to the RP would be distributed down to the > receivers. It would send a (*,G)-join with an (S,G) RPT prune. > Thus traffic from the (local) source would reach the (local) DR and the > receiver twice ???? > >>> Looking at the spec in Section 3.1 of RFC4601: >>> >>> "At the end of phase one, multicast traffic is flowing >>> encapsulated to >>> the RP, and then natively over the RP tree to the multicast >>> receivers." >> >> That is sort of the general picture, but any receivers connected to the >> first hop router (and also later any routers on the path from the FHR to >> the RP) would receive packets before this. >> > > I guess not: If multicast packets are tunneled in source register > packets, how can an intermediate router distribute them locally? I > suppose you are talking about PIM phase II, aren't you? There are no strict phases like that. FHR would create (S,G)-state when the first packet arrives. The (S,G) would have outgoing interfaces inherited from the (*,G) if there are local receivers that joined G. In addition it sends registers. Later when the RP joins the SPT to receive packets natively (not registers), you would create (S,G)-state and start receiving packets on routers between FHR and the RP. Also these would immediately send packets to local receivers (and pruning the source off the RPT), rather than waiting to receive packets on the RPT. Stig > Cheers, > > Thomas > > >>>> Some nits: >>>> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy >>>> or MLD Proxy >>>> 2) P14: This tree can be of lesser routing efficiency >>>> - This tree can be of less routing efficiency >>>> >>> >>> Thanks, it's fixed. >>> >>> Best regards, >>> >>> Thomas >>> >>>> Thanks! >>>> >>>> Best Regards, >>>> Cong Liu >>>> >>>> >>>> 2013/9/30 Thomas C. Schmidt >>> > >>>> >>>> Hi Dirk, >>>> >>>> thanks again for your detailed comments. Please see replies inline. >>>> >>>> On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de >>>> wrote: >>>> >>>> As promised at IETF-87 I did a review of the source multicast >>>> mobility draft and think the document is in quite good shape. >>>> >>>> Being not the distinct expert in details of multicast protocols >>>> I am not sure to have understood everything in detail, so >>>> please >>>> correct me and forgive misunderstandings ... >>>> >>>> The three scenarios described are >>>> 1) the base solution with MLD proxies at MAGs (and optionally >>>> also at LMAs) (sect.3) >>>> 2) direct routing with or without MLD proxies at MAGs and with >>>> native Multicast support at MAG level or above via different >>>> established Multicast protocols (sect.4) >>>> 3) Routing optimization for direct routing with MLD proxies at >>>> MAGs (sect. 5) >>>> Right? >>>> >>>> >>>> Yes, this is it. >>>> >>>> IMHO from the abstract this is not easily to see. >>>> >>>> >>>> We have adjusted the abstract. In any case, it explicitly addresses >>>> (enumerates) the three scenarios mentioned abobe. >>>> >>>> I have some comments and suggestions to increase >>>> readability, in >>>> addition to some nits found, given in the following: >>>> >>>> Fig. 1, fig.3 to be placed on single pages to simplify >>>> readability. >>>> >>>> >>>> This is a fine-tuning that shall be done with the RFC-editor. In >>>> the >>>> process of RFC-editing, the boilerplate will change and so will the >>>> positioning of floating text and figures. >>>> >>>> Consistently use re-attach and re-distribute _or_ reattach and >>>> redistribute, respectively, throughout document. >>>> Is there any implicit meaning of Proxy with respect to proxy? >>>> Also MLD Proxy and MLD proxy are both used throughout the >>>> document ... >>>> >>>> >>>> Thanks ... this should be corrected, now. >>>> >>>> >>>> p.1 >>>> optimizations for synchronizing PMIPv6 with PIM, as >>>> well as >>>> a peering >>>> function for MLD Proxies defined. >>>> => optimizations for synchronizing PMIPv6 with PIM, as >>>> well as >>>> a peering >>>> function for MLD Proxies are defined. >>>> >>>> >>>> Thanks, corrected. >>>> >>>> p.3 >>>> Such approaches (partially) follow the >>>> business model of providing multicast data services in >>>> parallel to >>>> PMIPv6 unicast routing. >>>> ==> shouldn't one or more references be added here such as to >>>> [I-D.ietf-multimob-pmipv6-__ropt], >>>> draft-ietf-multimob-fmipv6-__pfmipv6-multicast, >>>> draft-ietf-multimob-handover-__optimization ...? >>>> >>>> >>>> Yes, good point: It's added now. >>>> >>>> needs of receptive use cases >>>> => needs of applications for mobile multicast reception of >>>> content from few and mainly fixed content sources >>>> >>>> p.5 >>>> >>>> A multicast unaware MAG would simply discard these packets in >>>> the absence of a multicast routing information base >>>> (MRIB). >>>> ==> shouldn't one add more information about MRIBs introduced >>>> here for non-multicast aware readers such as: Such tables >>>> similar to MFIBs mentioned in RFC 6224 ensure that the >>>> router is >>>> able to correctly route/forward packets with multicast >>>> addresses >>>> as destinations . >>>> >>>> >>>> O.K. - we've added a brief explanatory insert ... even though I >>>> believe that a mulitcast unaware reader will not succeed in taking >>>> profit from this document ;) >>>> >>>> >>>> In case of a handover, the MN (unaware of IP mobility) >>>> => In case of a handover, the MN (being unaware of IP mobility) >>>> >>>> >>>> O.K., fixed. >>>> >>>> as soon as network connectivity is >>>> reconfigured >>>> => as soon as network connectivity is >>>> re-established >>>> >>>> O.K., fixed. >>>> >>>> >>>> p.7 >>>> multicast data is => multicast data are >>>> >>>> >>>> Mhmm, my dictionary says "data is" ... "data" is a singular term >>>> that subsumes (uncountable) plural ... >>>> >>>> >>>> p.8 >>>> In addition, an LMA serving as PIM Designated Router is >>>> connected >>>> => In addition, an LMA serving as PIM Designated Router >>>> (DR) is >>>> connected >>>> >>>> >>>> O.K., fixed. >>>> >>>> incoming interface validation is only performed by RPF >>>> checks >>>> => incoming interface validation is only performed by RPF >>>> (Reverse Path Forwarding) >>>> checks >>>> >>>> >>>> O.K., fixed. >>>> >>>> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust >>>> with >>>> respect to source location and does not require special >>>> configurations or state management for sources. >>>> ==> Wouldn't it make sense to add a reason for this, e.g. >>>> ... since BIDIR PIM automatically builds trees to allow >>>> multicast data to be natively forwarded from sources to >>>> receivers without requiring source-specific information ... >>>> On the other hand a reference to sect. 4.4 might be perhaps >>>> misleading here since this section is not on direct multicast >>>> routing?! >>>> >>>> >>>> This is about the nature of BIDIR-PIM. The reason for this property >>>> is the bidirectional use of a static (= source-independent) >>>> spanning >>>> tree ... but explaining the ideas behind BIDIR-PIM may really go >>>> too >>>> far here ... if readers haven't heard about BIDIR-PIM, the should >>>> look up the reference. >>>> >>>> >>>> an IGMP proxy >>>> function needs to be deployed at MAGs in exactly the same >>>> way as for >>>> IPv6. >>>> => an IGMP proxy >>>> function needs to be deployed at MAGs in exactly the same >>>> way as is done for an MLD proxy for >>>> IPv6. >>>> >>>> p.9 >>>> For a dual-stack IPv4/IPv6 access network, the MAG proxy >>>> instances >>>> => For a dual-stack IPv4/IPv6 access network, the MAG proxy >>>> instances (i.e. IPMP/MLD proxy functions) >>>> >>>> In the following, efficiency-related issues remain. >>>> => In the following, efficiency-related issues which remain >>>> unsolved within the above defined base PMIPv6 multicast source >>>> support are described. >>>> >>>> >>>> Here, we would prefer the shorter forms. >>>> >>>> p.11 >>>> upstream will lead traffic into the multicast infrastructure >>>> => upstream will transfer traffic into the multicast >>>> infrastructure >>>> >>>> >>>> o.k. >>>> >>>> p.12 >>>> configurations have completed => configurations have been >>>> completed >>>> >>>> >>>> o.k. >>>> >>>> traffic from the mobile source continues to be transmitted via >>>> the >>>> same next-hop router using the same source address >>>> => traffic from the mobile source continues to be transmitted >>>> via the >>>> same next-hop multicast router using the same source >>>> address >>>> >>>> >>>> o.k. >>>> >>>> by aggregating proxies on a lower layer. >>>> ==> please clarify: what layer exactly is proposed? PIM DR at >>>> MAGs? >>>> >>>> >>>> A lower layer is meant in the (OSI) layered model: Layer 2 or >>>> below. >>>> >>>> in the access network for providing multicast services in >>>> parallel to >>>> unicast routes. >>>> => in the access network for providing multicast services in >>>> parallel to >>>> unicast routes ( see Fig. 3(b)). >>>> >>>> >>>> O.K. >>>> >>>> p.13 >>>> The following information is needed for all phases of PIM. >>>> => The following information is needed for all three phases of >>>> PIM as outlined in [RFC4601]. >>>> >>>> >>>> O.K. >>>> >>>> P.14 >>>> configured to not initiated (S,G) shortest path tress for >>>> mobile >>>> => configured to not initiated (S,G) shortest path trees for >>>> mobile >>>> >>>> >>>> Thanks, o.k. >>>> >>>> mobile source. This tree can be of lesser routing efficiency >>>> than >>>> => mobile source. This tree can be of lower routing >>>> efficiency than >>>> >>>> >>>> o.k. >>>> >>>> In >>>> response, the PIM RP will recognize the known source at a >>>> new >>>> (tunnel) interface immediately responds with a register >>>> stop. >>>> => In >>>> response, the PIM RP will recognize the known source at a >>>> new >>>> (tunnel) interface and thus (?) immediately respond with a >>>> register stop. >>>> >>>> >>>> O.k., fixed. >>>> >>>> As the >>>> RP had joined the shortest path tree to receive from the >>>> source via >>>> the LMA, >>>> =>As the >>>> RP has joined the shortest path tree to receive data from >>>> the source via >>>> the LMA, >>>> >>>> >>>> Meanwhile replaced. >>>> >>>> the LMA, it will see an RPF change when data arrives at a new >>>> => the LMA, it will see an RPF change when data arrive at a new >>>> >>>> >>>> s.o. >>>> >>>> In response to an exceeded threshold of packet transmission, >>>> DRs of >>>> receivers eventually will initiated a source-specific >>>> Join for >>>> => In response to an exceeded threshold of packet transmission, >>>> DRs of >>>> receivers eventually will initiate a source-specific Join >>>> for >>>> >>>> >>>> Thanks, fixed. >>>> >>>> this (S,G) tree will range from >>>> the receiving DR via the (stable) LMA, the LMA-MAG tunnel >>>> to the >>>> mobile source >>>> => >>>> this (S,G) tree will range from >>>> the receiving DR via the (stable) LMA, the LMA-MAG tunnel, >>>> and the serving MAG to the >>>> mobile source (described from leave to root?) >>>> >>>> >>>> o.k. >>>> >>>> This tree is of higher routing efficiency than >>>> established in the previous phase two >>>> => >>>> This tree is of higher routing efficiency than >>>> that established in the previous phase two >>>> >>>> >>>> thanks, o.k. >>>> >>>> p.15 >>>> via the source register tunnel. Tree mainenance eventually >>>> triggered >>>> => via the source register tunnel. Tree maintenance eventually >>>> triggered >>>> >>>> >>>> Thanks, o.k. >>>> >>>> p.16 >>>> BIDIR-PIM MAY be deployed in the access network => >>>> BIDIR-PIM [RFC5015] MAY be deployed in the access network >>>> >>>> >>>> Ref has been provided before. >>>> >>>> remain uneffected by node mobility => remain unaffected by node >>>> mobility >>>> >>>> >>>> Thanks, fixed. >>>> >>>> spanning group tree => spanning tree for the multicast group >>>> /multicast spanning tree >>>> >>>> >>>> o.k., thanks. >>>> >>>> p.17 >>>> document. To overcome these deficits, an optimized approach to >>>> ==> AFAIU it does mainly cover deficits mentioned in sect. >>>> 4, if >>>> also those inefficiencies described in 3.2.5 are tackled this >>>> should be explained >>>> >>>> >>>> Actually, the main concerns that are addressed in this peering >>>> approach are from section 3.2.5, namely the parallel proxy >>>> instances, which route via an LMA. >>>> >>>> We've added text to make this clearer. >>>> >>>> >>>> Following different techniques, these requirements are met in >>>> the >>>> following solutions. >>>> ==> to me it seems to be one solution only (peering between MLD >>>> proxies) adapted to several multicast protocol implementations >>>> for ASM and SSM >>>> >>>> >>>> Yes, the original text covered also the multiple-upstream proxy, >>>> which moved to the appendix now. The text has been corrected now. >>>> >>>> but provide superior performance in the presence of source- >>>> specific signaling (IGMPv3/MLDv2). >>>> ==> Wouldn't a reference to RFC 4604 ("Using Internet Group >>>> Management Protocol Version 3 (IGMPv3) and Multicast Listener >>>> Discovery Protocol Version 2 (MLDv2) for Source-Specific >>>> Multicast") make sense or be helpful here? >>>> >>>> >>>> O.k., we've added this. >>>> >>>> >>>> p.18 >>>> This filter base Must be updated, if and => This filter base >>>> MUST be updated, if and >>>> >>>> >>>> thanks, fixed. >>>> >>>> In >>>> addition, local multicast packets are transferred >>>> => >>>> In >>>> addition, multicast packets from locally attached sources >>>> are transferred >>>> or: >>>> In addition, such locally arriving multicast packets are >>>> transferred >>>> >>>> >>>> O.k., reworded. >>>> >>>> p.19 >>>> 6. IANA Considerations >>>> TODO. >>>> ==> to me there seem to be no IANA activities arising from the >>>> proposed protocol modifications, right? >>>> >>>> >>>> Yes. >>>> >>>> p.20 >>>> the PMIPv6 domain will not actively terminate group membership >>>> prior >>>> to departure. >>>> => >>>> the PMIPv6 domain will in general not actively terminate group >>>> membership prior >>>> to departure. >>>> >>>> >>>> o.k. >>>> >>>> p.22 >>>> but alternate configuriations => but alternate configurations >>>> >>>> a state decomposition , if needed => a state decomposition, if >>>> needed... >>>> >>>> >>>> Thanks, fixed. >>>> >>>> Hope this helps. >>>> >>>> >>>> Yes, thanks a lot for this detailed review! >>>> >>>> Best wishes, >>>> >>>> Thomas >>>> >>>> >>>> -----Original Message----- >>>> From: multimob-bounces@ietf.org >>>> >>>> [mailto:multimob-bounces@ietf.__org >>>> ] On Behalf Of >>>> internet-drafts@ietf.org >>>> Sent: Samstag, 13. Juli 2013 00:50 >>>> To: i-d-announce@ietf.org >>>> Cc: multimob@ietf.org >>>> Subject: [multimob] I-D Action: >>>> draft-ietf-multimob-pmipv6-__source-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> This draft is a work item of the Multicast Mobility Working >>>> Group of the IETF. >>>> >>>> Title : Mobile Multicast Sender Support in >>>> Proxy Mobile IPv6 (PMIPv6) Domains >>>> Author(s) : Thomas C. Schmidt >>>> Shuai Gao >>>> Hong-Ke Zhang >>>> Matthias Waehlisch >>>> Filename : >>>> draft-ietf-multimob-pmipv6-__source-04.txt >>>> Pages : 24 >>>> Date : 2013-07-12 >>>> >>>> Abstract: >>>> Multicast communication can be enabled in Proxy Mobile >>>> IPv6 >>>> domains >>>> via the Local Mobility Anchors by deploying MLD Proxy >>>> functions at >>>> Mobile Access Gateways, via a direct traffic distribution >>>> within an >>>> ISP's access network, or by selective route optimization >>>> schemes. >>>> This document describes the support of mobile multicast >>>> senders in >>>> Proxy Mobile IPv6 domains for all three scenarios. >>>> Protocol >>>> optimizations for synchronizing PMIPv6 with PIM, as >>>> well as >>>> a peering >>>> function for MLD Proxies defined. Mobile sources always >>>> remain >>>> agnostic of multicast mobility operations. >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> >>>> https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source >>>> >>>> >>>> >>>> There's also a htmlized version available at: >>>> >>>> http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04 >>>> >>>> >>>> >>>> A diff from the previous version is available at: >>>> >>>> http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04 >>>> >>>> >>>> >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-__drafts/ >>>> >>>> >>>> _________________________________________________ >>>> 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 sarikaya2012@gmail.com Tue Oct 1 11:58:19 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983BD11E81B9 for ; Tue, 1 Oct 2013 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Os0wDZKjh5t for ; Tue, 1 Oct 2013 11:58:14 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E811E81AD for ; Tue, 1 Oct 2013 11:58:09 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so6368991lab.30 for ; Tue, 01 Oct 2013 11:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L08UrtsVNjkPsyT1M0Vz44ELGg8n/iEV2SV1kzwmtZQ=; b=NkFGr/nalKNXWgUMG3MvkJP9m9jqgij5jwg/16GSV2Ihm2nVhPllVMCud77lEpuhlv yfZrpHvtcfp1vLu6XuQ/ohgZR9QpyILYJorYn2gyclS6JOavKiJNHT1ejAeQNRpeu64R MLOz7Ptifehfuyh4Fa0lzjLgdTh7tE34+jKVtOsV5FLO15jsDlFuehbQfvilQlWFnqh8 pAQL9LfWwwn9P1eWQ7sS/OJP/6r4UG6pNQzwff7XhKpSiorns3C7Q3kXO7B7F7DwgAtz bRwOQAit3TwXsRJtjGQrHodERavlEAEjLjUQnRjgqxbeoJKu0EZ3U2BGyiUzZyAHXcEA 2OMA== MIME-Version: 1.0 X-Received: by 10.112.143.3 with SMTP id sa3mr27969661lbb.12.1380653888582; Tue, 01 Oct 2013 11:58:08 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 1 Oct 2013 11:58:08 -0700 (PDT) In-Reply-To: <524B0301.8080301@venaas.com> References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com> <5249E105.8040405@informatik.haw-hamburg.de> <524B0301.8080301@venaas.com> Date: Tue, 1 Oct 2013 13:58:08 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: multipart/alternative; boundary=089e011827ae963adf04e7b288e2 Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:58:19 -0000 --089e011827ae963adf04e7b288e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You mean a certain implementation has somehow foreseen these and acting like this? Otherwise you need to provide references. Regards, Behcet On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas wrote: > Hi > > > On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote: > >> Hi Stig, >> >> you're the PIM expert ... however, your statements confuse me. >> >> Event though the discussion does not matter to the source draft, I would >> like to clarify. Please see inline. >> >> On 30.09.2013 21:19, Stig Venaas wrote: >> >>> Hi >>> >>> On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote: >>> >>>> Dear Cong Liu, >>>> >>>> thanks for your feedback - please see inline. >>>> >>>> On 30.09.2013 08:47, Cong Liu wrote: >>>> >>>> Regarding this draft, I have the following comments for consideration= . >>>>> >>>>> P14: "This tree can be of lesser routing efficiency than the PIM sour= ce >>>>> register tunnel established in phase one, but provides the advantage = of >>>>> immediate data delivery to receivers that share a MAG with S." >>>>> - This sentence implicitly indicates that local receivers sharing a M= AG >>>>> with S cannot receive immediate multicast traffic from the S in phase >>>>> one. In my opinion, even in phase one, the MAG acting as the DR has t= he >>>>> related multicast state so that immediate data delivery is possible. = If >>>>> so, the sentence here is not appropriate. >>>>> >>>>> >>>> This sentence actually refers to the building of an (S,G)-Tree at the >>>> end of PIM phase II. This tree follows reverse unicast routes and thus >>>> traverses the LMA-MAG tunnel - this is why it may be of lower efficien= cy >>>> than the forward (register) tunnel in phase I. >>>> >>>> What you are referring to is the question of source-local traffic >>>> distribution in PIM phase I. According to the way I understand PIM-SM= , >>>> it does not distribute source-specific traffic locally in Phase I. Thi= s >>>> is because a local source S generates an (S,G)-State at the sender's >>>> local router (DR), but a receiver in ASM requires an (*,G) service. >>>> >>> >>> Traffic is distributed locally independent of the registration process. >>> I assume you're talking about a source on one interface, and receivers >>> on other interfaces on the same router? In that case for ASM (receivers >>> joining a group, not specific sources), there would already be >>> (*,G)-join state, and packets from the source would both be forwarded >>> on the joined interfaces and sent as PIM registers. >>> >>> >> Mhmm ... this would mean that you have two feeds into the distribution >> tree: One rooted at the source (valid for local receivers), and one >> rooted at the RP - at this stage, we are still in phase I. >> > > If you're receiving packets from the source you're already on the > SPT and prune the source from the shared tree. > > > If (S,G) traffic were distributed locally, then the required (*,G)-Join >>>> to the RP would cause duplicate (S,G) traffic arriving at the >>>> source-local receiver. >>>> >>> >>> No, that shouldn't happen. >>> >>> >> How do you exclude? In phase I, all traffic is tunneled to the RP and >> the "path" from source to RP is not visible to the multicast >> distribution system. The DR of the receiver, which happens to be the DR >> of one of the sources, would just initiate an (*,G) join towards the RP >> ... and all traffic tunneled to the RP would be distributed down to the >> receivers. >> > > It would send a (*,G)-join with an (S,G) RPT prune. > > > Thus traffic from the (local) source would reach the (local) DR and the >> receiver twice ???? >> >> Looking at the spec in Section 3.1 of RFC4601: >>>> >>>> "At the end of phase one, multicast traffic is flowing >>>> encapsulated to >>>> the RP, and then natively over the RP tree to the multicast >>>> receivers." >>>> >>> >>> That is sort of the general picture, but any receivers connected to the >>> first hop router (and also later any routers on the path from the FHR t= o >>> the RP) would receive packets before this. >>> >>> >> I guess not: If multicast packets are tunneled in source register >> packets, how can an intermediate router distribute them locally? I >> suppose you are talking about PIM phase II, aren't you? >> > > There are no strict phases like that. > > FHR would create (S,G)-state when the first packet arrives. The (S,G) > would have outgoing interfaces inherited from the (*,G) if there are > local receivers that joined G. In addition it sends registers. > > Later when the RP joins the SPT to receive packets natively (not > registers), you would create (S,G)-state and start receiving packets > on routers between FHR and the RP. Also these would immediately > send packets to local receivers (and pruning the source off the RPT), > rather than waiting to receive packets on the RPT. > > Stig > > > Cheers, >> >> Thomas >> >> >> Some nits: >>>>> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD prox= y >>>>> or MLD Proxy >>>>> 2) P14: This tree can be of lesser routing efficiency >>>>> - This tree can be of less routing efficiency >>>>> >>>>> >>>> Thanks, it's fixed. >>>> >>>> Best regards, >>>> >>>> Thomas >>>> >>>> Thanks! >>>>> >>>>> Best Regards, >>>>> Cong Liu >>>>> >>>>> >>>>> 2013/9/30 Thomas C. Schmidt >>>>> >>>>> >> >>>>> >>>>> Hi Dirk, >>>>> >>>>> thanks again for your detailed comments. Please see replies inlin= e. >>>>> >>>>> On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de >>>>> > >>>>> wrote: >>>>> >>>>> As promised at IETF-87 I did a review of the source multicast >>>>> mobility draft and think the document is in quite good shape. >>>>> >>>>> Being not the distinct expert in details of multicast protoco= ls >>>>> I am not sure to have understood everything in detail, so >>>>> please >>>>> correct me and forgive misunderstandings ... >>>>> >>>>> The three scenarios described are >>>>> 1) the base solution with MLD proxies at MAGs (and optionally >>>>> also at LMAs) (sect.3) >>>>> 2) direct routing with or without MLD proxies at MAGs and wit= h >>>>> native Multicast support at MAG level or above via different >>>>> established Multicast protocols (sect.4) >>>>> 3) Routing optimization for direct routing with MLD proxies a= t >>>>> MAGs (sect. 5) >>>>> Right? >>>>> >>>>> >>>>> Yes, this is it. >>>>> >>>>> IMHO from the abstract this is not easily to see. >>>>> >>>>> >>>>> We have adjusted the abstract. In any case, it explicitly address= es >>>>> (enumerates) the three scenarios mentioned abobe. >>>>> >>>>> I have some comments and suggestions to increase >>>>> readability, in >>>>> addition to some nits found, given in the following: >>>>> >>>>> Fig. 1, fig.3 to be placed on single pages to simplify >>>>> readability. >>>>> >>>>> >>>>> This is a fine-tuning that shall be done with the RFC-editor. In >>>>> the >>>>> process of RFC-editing, the boilerplate will change and so will t= he >>>>> positioning of floating text and figures. >>>>> >>>>> Consistently use re-attach and re-distribute _or_ reattach an= d >>>>> redistribute, respectively, throughout document. >>>>> Is there any implicit meaning of Proxy with respect to proxy? >>>>> Also MLD Proxy and MLD proxy are both used throughout the >>>>> document ... >>>>> >>>>> >>>>> Thanks ... this should be corrected, now. >>>>> >>>>> >>>>> p.1 >>>>> optimizations for synchronizing PMIPv6 with PIM, as >>>>> well as >>>>> a peering >>>>> function for MLD Proxies defined. >>>>> =3D> optimizations for synchronizing PMIPv6 with PIM, as >>>>> well as >>>>> a peering >>>>> function for MLD Proxies are defined. >>>>> >>>>> >>>>> Thanks, corrected. >>>>> >>>>> p.3 >>>>> Such approaches (partially) follow the >>>>> business model of providing multicast data services in >>>>> parallel to >>>>> PMIPv6 unicast routing. >>>>> =3D=3D> shouldn't one or more references be added here such a= s to >>>>> [I-D.ietf-multimob-pmipv6-__**ropt], >>>>> draft-ietf-multimob-fmipv6-__**pfmipv6-multicast, >>>>> draft-ietf-multimob-handover-_**_optimization ...? >>>>> >>>>> >>>>> Yes, good point: It's added now. >>>>> >>>>> needs of receptive use cases >>>>> =3D> needs of applications for mobile multicast reception of >>>>> content from few and mainly fixed content sources >>>>> >>>>> p.5 >>>>> >>>>> A multicast unaware MAG would simply discard these packets in >>>>> the absence of a multicast routing information base >>>>> (MRIB). >>>>> =3D=3D> shouldn't one add more information about MRIBs introd= uced >>>>> here for non-multicast aware readers such as: Such tables >>>>> similar to MFIBs mentioned in RFC 6224 ensure that the >>>>> router is >>>>> able to correctly route/forward packets with multicast >>>>> addresses >>>>> as destinations . >>>>> >>>>> >>>>> O.K. - we've added a brief explanatory insert ... even though I >>>>> believe that a mulitcast unaware reader will not succeed in takin= g >>>>> profit from this document ;) >>>>> >>>>> >>>>> In case of a handover, the MN (unaware of IP mobility) >>>>> =3D> In case of a handover, the MN (being unaware of IP mobil= ity) >>>>> >>>>> >>>>> O.K., fixed. >>>>> >>>>> as soon as network connectivity is >>>>> reconfigured >>>>> =3D> as soon as network connectivity is >>>>> re-established >>>>> >>>>> O.K., fixed. >>>>> >>>>> >>>>> p.7 >>>>> multicast data is =3D> multicast data are >>>>> >>>>> >>>>> Mhmm, my dictionary says "data is" ... "data" is a singular term >>>>> that subsumes (uncountable) plural ... >>>>> >>>>> >>>>> p.8 >>>>> In addition, an LMA serving as PIM Designated Router is >>>>> connected >>>>> =3D> In addition, an LMA serving as PIM Designated Router >>>>> (DR) is >>>>> connected >>>>> >>>>> >>>>> O.K., fixed. >>>>> >>>>> incoming interface validation is only performed by RPF >>>>> checks >>>>> =3D> incoming interface validation is only performed by RPF >>>>> (Reverse Path Forwarding) >>>>> checks >>>>> >>>>> >>>>> O.K., fixed. >>>>> >>>>> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust >>>>> with >>>>> respect to source location and does not require special >>>>> configurations or state management for sources. >>>>> =3D=3D> Wouldn't it make sense to add a reason for this, e.g. >>>>> ... since BIDIR PIM automatically builds trees to allow >>>>> multicast data to be natively forwarded from sources to >>>>> receivers without requiring source-specific information ... >>>>> On the other hand a reference to sect. 4.4 might be perhaps >>>>> misleading here since this section is not on direct multicast >>>>> routing?! >>>>> >>>>> >>>>> This is about the nature of BIDIR-PIM. The reason for this proper= ty >>>>> is the bidirectional use of a static (=3D source-independent) >>>>> spanning >>>>> tree ... but explaining the ideas behind BIDIR-PIM may really go >>>>> too >>>>> far here ... if readers haven't heard about BIDIR-PIM, the should >>>>> look up the reference. >>>>> >>>>> >>>>> an IGMP proxy >>>>> function needs to be deployed at MAGs in exactly the sam= e >>>>> way as for >>>>> IPv6. >>>>> =3D> an IGMP proxy >>>>> function needs to be deployed at MAGs in exactly the sam= e >>>>> way as is done for an MLD proxy for >>>>> IPv6. >>>>> >>>>> p.9 >>>>> For a dual-stack IPv4/IPv6 access network, the MAG proxy >>>>> instances >>>>> =3D> For a dual-stack IPv4/IPv6 access network, the MAG proxy >>>>> instances (i.e. IPMP/MLD proxy functions) >>>>> >>>>> In the following, efficiency-related issues remain. >>>>> =3D> In the following, efficiency-related issues which remain >>>>> unsolved within the above defined base PMIPv6 multicast sourc= e >>>>> support are described. >>>>> >>>>> >>>>> Here, we would prefer the shorter forms. >>>>> >>>>> p.11 >>>>> upstream will lead traffic into the multicast infrastructure >>>>> =3D> upstream will transfer traffic into the multicast >>>>> infrastructure >>>>> >>>>> >>>>> o.k. >>>>> >>>>> p.12 >>>>> configurations have completed =3D> configurations have been >>>>> completed >>>>> >>>>> >>>>> o.k. >>>>> >>>>> traffic from the mobile source continues to be transmitted vi= a >>>>> the >>>>> same next-hop router using the same source address >>>>> =3D> traffic from the mobile source continues to be transmit= ted >>>>> via the >>>>> same next-hop multicast router using the same source >>>>> address >>>>> >>>>> >>>>> o.k. >>>>> >>>>> by aggregating proxies on a lower layer. >>>>> =3D=3D> please clarify: what layer exactly is proposed? PIM D= R at >>>>> MAGs? >>>>> >>>>> >>>>> A lower layer is meant in the (OSI) layered model: Layer 2 or >>>>> below. >>>>> >>>>> in the access network for providing multicast services in >>>>> parallel to >>>>> unicast routes. >>>>> =3D> in the access network for providing multicast services = in >>>>> parallel to >>>>> unicast routes ( see Fig. 3(b)). >>>>> >>>>> >>>>> O.K. >>>>> >>>>> p.13 >>>>> The following information is needed for all phases of PIM= . >>>>> =3D> The following information is needed for all three phase= s of >>>>> PIM as outlined in [RFC4601]. >>>>> >>>>> >>>>> O.K. >>>>> >>>>> P.14 >>>>> configured to not initiated (S,G) shortest path tress for >>>>> mobile >>>>> =3D> configured to not initiated (S,G) shortest path trees fo= r >>>>> mobile >>>>> >>>>> >>>>> Thanks, o.k. >>>>> >>>>> mobile source. This tree can be of lesser routing efficiency >>>>> than >>>>> =3D> mobile source. This tree can be of lower routing >>>>> efficiency than >>>>> >>>>> >>>>> o.k. >>>>> >>>>> In >>>>> response, the PIM RP will recognize the known source at = a >>>>> new >>>>> (tunnel) interface immediately responds with a register >>>>> stop. >>>>> =3D> In >>>>> response, the PIM RP will recognize the known source at = a >>>>> new >>>>> (tunnel) interface and thus (?) immediately respond with= a >>>>> register stop. >>>>> >>>>> >>>>> O.k., fixed. >>>>> >>>>> As the >>>>> RP had joined the shortest path tree to receive from the >>>>> source via >>>>> the LMA, >>>>> =3D>As the >>>>> RP has joined the shortest path tree to receive data fro= m >>>>> the source via >>>>> the LMA, >>>>> >>>>> >>>>> Meanwhile replaced. >>>>> >>>>> the LMA, it will see an RPF change when data arrives at a new >>>>> =3D> the LMA, it will see an RPF change when data arrive at a= new >>>>> >>>>> >>>>> s.o. >>>>> >>>>> In response to an exceeded threshold of packet transmission, >>>>> DRs of >>>>> receivers eventually will initiated a source-specific >>>>> Join for >>>>> =3D> In response to an exceeded threshold of packet transmiss= ion, >>>>> DRs of >>>>> receivers eventually will initiate a source-specific Joi= n >>>>> for >>>>> >>>>> >>>>> Thanks, fixed. >>>>> >>>>> this (S,G) tree will range from >>>>> the receiving DR via the (stable) LMA, the LMA-MAG tunne= l >>>>> to the >>>>> mobile source >>>>> =3D> >>>>> this (S,G) tree will range from >>>>> the receiving DR via the (stable) LMA, the LMA-MAG tunne= l, >>>>> and the serving MAG to the >>>>> mobile source (described from leave to root?) >>>>> >>>>> >>>>> o.k. >>>>> >>>>> This tree is of higher routing efficiency than >>>>> established in the previous phase two >>>>> =3D> >>>>> This tree is of higher routing efficiency than >>>>> that established in the previous phase two >>>>> >>>>> >>>>> thanks, o.k. >>>>> >>>>> p.15 >>>>> via the source register tunnel. Tree mainenance eventually >>>>> triggered >>>>> =3D> via the source register tunnel. Tree maintenance eventu= ally >>>>> triggered >>>>> >>>>> >>>>> Thanks, o.k. >>>>> >>>>> p.16 >>>>> BIDIR-PIM MAY be deployed in the access network =3D> >>>>> BIDIR-PIM [RFC5015] MAY be deployed in the access network >>>>> >>>>> >>>>> Ref has been provided before. >>>>> >>>>> remain uneffected by node mobility =3D> remain unaffected by = node >>>>> mobility >>>>> >>>>> >>>>> Thanks, fixed. >>>>> >>>>> spanning group tree =3D> spanning tree for the multicast grou= p >>>>> /multicast spanning tree >>>>> >>>>> >>>>> o.k., thanks. >>>>> >>>>> p.17 >>>>> document. To overcome these deficits, an optimized approach = to >>>>> =3D=3D> AFAIU it does mainly cover deficits mentioned in sect= . >>>>> 4, if >>>>> also those inefficiencies described in 3.2.5 are tackled this >>>>> should be explained >>>>> >>>>> >>>>> Actually, the main concerns that are addressed in this peering >>>>> approach are from section 3.2.5, namely the parallel proxy >>>>> instances, which route via an LMA. >>>>> >>>>> We've added text to make this clearer. >>>>> >>>>> >>>>> Following different techniques, these requirements are met in >>>>> the >>>>> following solutions. >>>>> =3D=3D> to me it seems to be one solution only (peering betwe= en MLD >>>>> proxies) adapted to several multicast protocol implementation= s >>>>> for ASM and SSM >>>>> >>>>> >>>>> Yes, the original text covered also the multiple-upstream proxy, >>>>> which moved to the appendix now. The text has been corrected now. >>>>> >>>>> but provide superior performance in the presence of source- >>>>> specific signaling (IGMPv3/MLDv2). >>>>> =3D=3D> Wouldn't a reference to RFC 4604 ("Using Internet Gro= up >>>>> Management Protocol Version 3 (IGMPv3) and Multicast Listener >>>>> Discovery Protocol Version 2 (MLDv2) for Source-Specific >>>>> Multicast") make sense or be helpful here? >>>>> >>>>> >>>>> O.k., we've added this. >>>>> >>>>> >>>>> p.18 >>>>> This filter base Must be updated, if and =3D> This filter bas= e >>>>> MUST be updated, if and >>>>> >>>>> >>>>> thanks, fixed. >>>>> >>>>> In >>>>> addition, local multicast packets are transferred >>>>> =3D> >>>>> In >>>>> addition, multicast packets from locally attached source= s >>>>> are transferred >>>>> or: >>>>> In addition, such locally arriving multicast packets are >>>>> transferred >>>>> >>>>> >>>>> O.k., reworded. >>>>> >>>>> p.19 >>>>> 6. IANA Considerations >>>>> TODO. >>>>> =3D=3D> to me there seem to be no IANA activities arising fro= m the >>>>> proposed protocol modifications, right? >>>>> >>>>> >>>>> Yes. >>>>> >>>>> p.20 >>>>> the PMIPv6 domain will not actively terminate group membershi= p >>>>> prior >>>>> to departure. >>>>> =3D> >>>>> the PMIPv6 domain will in general not actively terminate grou= p >>>>> membership prior >>>>> to departure. >>>>> >>>>> >>>>> o.k. >>>>> >>>>> p.22 >>>>> but alternate configuriations =3D> but alternate configuratio= ns >>>>> >>>>> a state decomposition , if needed =3D> a state decomposition,= if >>>>> needed... >>>>> >>>>> >>>>> Thanks, fixed. >>>>> >>>>> Hope this helps. >>>>> >>>>> >>>>> Yes, thanks a lot for this detailed review! >>>>> >>>>> Best wishes, >>>>> >>>>> Thomas >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: multimob-bounces@ietf.org >>>>> >>>>> > >>>>> [mailto:multimob-bounces@ietf.**__org >>>>> >] >>>>> On Behalf Of >>>>> internet-drafts@ietf.org >>>>> > >>>>> Sent: Samstag, 13. Juli 2013 00:50 >>>>> To: i-d-announce@ietf.org >>>>> Cc: multimob@ietf.org >>>>> Subject: [multimob] I-D Action: >>>>> draft-ietf-multimob-pmipv6-__**source-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>> This draft is a work item of the Multicast Mobility Workin= g >>>>> Group of the IETF. >>>>> >>>>> Title : Mobile Multicast Sender Support in >>>>> Proxy Mobile IPv6 (PMIPv6) Domains >>>>> Author(s) : Thomas C. Schmidt >>>>> Shuai Gao >>>>> Hong-Ke Zhang >>>>> Matthias Waehlisch >>>>> Filename : >>>>> draft-ietf-multimob-pmipv6-__**source-04.txt >>>>> Pages : 24 >>>>> Date : 2013-07-12 >>>>> >>>>> Abstract: >>>>> Multicast communication can be enabled in Proxy Mobile >>>>> IPv6 >>>>> domains >>>>> via the Local Mobility Anchors by deploying MLD Proxy >>>>> functions at >>>>> Mobile Access Gateways, via a direct traffic distributio= n >>>>> within an >>>>> ISP's access network, or by selective route optimization >>>>> schemes. >>>>> This document describes the support of mobile multicast >>>>> senders in >>>>> Proxy Mobile IPv6 domains for all three scenarios. >>>>> Protocol >>>>> optimizations for synchronizing PMIPv6 with PIM, as >>>>> well as >>>>> a peering >>>>> function for MLD Proxies defined. Mobile sources always >>>>> remain >>>>> agnostic of multicast mobility operations. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>> https://datatracker.ietf.org/_**_doc/draft-ietf-multimob-__** >>>>> pmipv6-source >>>>> >>>>> >>>> pmipv6-source >>>>> > >>>>> >>>>> There's also a htmlized version available at: >>>>> >>>>> http://tools.ietf.org/html/__**draft-ietf-multimob-pmipv6-__** >>>>> source-04 >>>>> >>>>> >>>>> > >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> http://www.ietf.org/rfcdiff?__**url2=3Ddraft-ietf-multimob-__** >>>>> pmipv6-source-04 >>>>> >>>>> >>>>> >>>>> >>>> pmipv6-source-04 >>>>> > >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-__**drafts/ >>>>> >>>>> > >>>>> >>>>> ______________________________**___________________ >>>>> multimob mailing list >>>>> multimob@ietf.org >>>>> https://www.ietf.org/mailman/_**_listinfo/multimob >>>>> >>>>> > >>>>> >>>>> >>>>> -- >>>>> >>>>> Prof. Dr. Thomas C. Schmidt >>>>> =B0 Hamburg University of Applied Sciences Berl= iner >>>>> Tor 7 =B0 >>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hambur= g, >>>>> Germany =B0 >>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>> +49-40-42875-8452 =B0 >>>>> =B0 http://www.informatik.haw-__**hamburg.de/~schmidt >>>>> > >>>>> Fax: >>>>> +49-40-42875-8409 =B0 >>>>> ______________________________**___________________ >>>>> multimob mailing list >>>>> multimob@ietf.org >>>>> https://www.ietf.org/mailman/_**_listinfo/multimob >>>>> >>>>> > >>>>> >>>>> >>>>> >>>> >>> >> > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --089e011827ae963adf04e7b288e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You mean a certain implementation has someh= ow foreseen these and acting like this?

Otherwise you need to = provide references.

Regards,

Behcet


On Tue, Oct 1, 2013 at 12:14 PM, Stig Ve= naas <stig@venaas.com> wrote:


On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote:
Hi Stig,

you're the PIM expert ... however, your statements confuse me.

Event though the discussion does not matter to the source draft, I would like to clarify. Please see inline.

On 30.09.2013 21:19, Stig Venaas wrote:
Hi

On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote:
Dear Cong Liu,

thanks for your feedback - please see inline.

On 30.09.2013 08:47, Cong Liu wrote:

Regarding this draft, I have the following comments for consideration.

P14: "This tree can be of lesser routing efficiency than the PIM sourc= e
register tunnel established in phase one, but provides the advantage of
immediate data delivery to receivers that share a MAG with S."
- This sentence implicitly indicates that local receivers sharing a MAG
with S cannot receive immediate multicast traffic from the S in phase
one. In my opinion, even in phase one, the MAG acting as the DR has the
related multicast state so that immediate data delivery is possible. If
so, the sentence here is not appropriate.


This sentence actually refers to the building of an (S,G)-Tree at the
end of PIM phase II. This tree follows reverse unicast routes and thus
traverses the LMA-MAG tunnel - this is why it may be of lower efficiency than the forward (register) tunnel in phase I.

What you are referring to is the question of source-local traffic
distribution in PIM phase I. According to the way I understand =A0PIM-SM, it does not distribute source-specific traffic locally in Phase I. This
is because a local source S generates an (S,G)-State at the sender's local router (DR), but a receiver in ASM requires an (*,G) service.

Traffic is distributed locally independent of the registration process.
I assume you're talking about a source on one interface, and receivers<= br> on other interfaces on the same router? In that case for ASM (receivers
joining a group, not specific sources), there would already be
(*,G)-join state, and packets from the source would both be forwarded
on the joined interfaces and sent as PIM registers.


Mhmm ... this would mean that you have two feeds into the distribution
tree: One rooted at the source (valid for local receivers), and one
rooted at the RP - at this stage, we are still in phase I.

If you're receiving packets from the source you're already on the SPT and prune the source from the shared tree.


If (S,G) traffic were distributed locally, then the required (*,G)-Join
to the RP would cause duplicate (S,G) traffic arriving at the
source-local receiver.

No, that shouldn't happen.


How do you exclude? In phase I, all traffic is tunneled to the RP and
the "path" from source to RP is not visible to the multicast
distribution system. The DR of the receiver, which happens to be the DR
of one of the sources, would just initiate an (*,G) join towards the RP
... and all traffic tunneled to the RP would be distributed down to the
receivers.

It would send a (*,G)-join with an (S,G) RPT prune.


Thus traffic from the (local) source would reach the (local) DR and the
receiver twice ????

Looking at the spec in Section 3.1 of RFC4601:

=A0 =A0"At the end of phase one, multicast traffic is flowing
encapsulated to
=A0 =A0 the RP, and then natively over the RP tree to the multicast
receivers."

That is sort of the general picture, but any receivers connected to the
first hop router (and also later any routers on the path from the FHR to the RP) would receive packets before this.


I guess not: If multicast packets are tunneled in source register
packets, how can an intermediate router distribute them locally? I
suppose you are talking about PIM phase II, aren't you?

There are no strict phases like that.

FHR would create (S,G)-state when the first packet arrives. The (S,G)
would have outgoing interfaces inherited from the (*,G) if there are
local receivers that joined G. In addition it sends registers.

Later when the RP joins the SPT to receive packets natively (not
registers), you would create (S,G)-state and start receiving packets
on routers between FHR and the RP. Also these would immediately
send packets to local receivers (and pruning the source off the RPT),
rather than waiting to receive packets on the RPT.

Stig


Cheers,

Thomas


Some nits:
1) The term "MLD proxy" and "MLD Proxy" should be unifi= ed as MLD proxy
or MLD Proxy
2) P14: This tree can be of lesser routing efficiency
- This tree can be of less routing efficiency


Thanks, it's fixed.

Best regards,

Thomas

Thanks!

Best Regards,
Cong Liu


2013/9/30 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de <mailto:schmidt@informatik.haw-hamburg.de>>

=A0 =A0 Hi Dirk,

=A0 =A0 thanks again for your detailed comments. Please see replies inline.=

=A0 =A0 On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de
=A0 =A0 <mailto:Dirk.von-Hugo@telekom.de> wrote:

=A0 =A0 =A0 =A0 As promised at IETF-87 I did a review of the source multica= st
=A0 =A0 =A0 =A0 mobility draft and think the document is in quite good shap= e.

=A0 =A0 =A0 =A0 Being not the distinct expert in details of multicast proto= cols
=A0 =A0 =A0 =A0 I am not sure to have understood everything in detail, so please
=A0 =A0 =A0 =A0 correct me and forgive misunderstandings ...

=A0 =A0 =A0 =A0 The three scenarios described are
=A0 =A0 =A0 =A0 1) the base solution with MLD proxies at MAGs (and optional= ly
=A0 =A0 =A0 =A0 also at LMAs) (sect.3)
=A0 =A0 =A0 =A0 2) direct routing with or without MLD proxies at MAGs and w= ith
=A0 =A0 =A0 =A0 native Multicast support at MAG level or above via differen= t
=A0 =A0 =A0 =A0 established Multicast protocols (sect.4)
=A0 =A0 =A0 =A0 3) Routing optimization for direct routing with MLD proxies= at
=A0 =A0 =A0 =A0 MAGs (sect. 5)
=A0 =A0 =A0 =A0 Right?


=A0 =A0 Yes, this is it.

=A0 =A0 =A0 =A0 IMHO from the abstract this is not easily to see.


=A0 =A0 We have adjusted the abstract. In any case, it explicitly addresses=
=A0 =A0 (enumerates) the three scenarios mentioned abobe.

=A0 =A0 =A0 =A0 I have some comments and suggestions to increase
readability, in
=A0 =A0 =A0 =A0 addition to some nits found, given in the following:

=A0 =A0 =A0 =A0 Fig. 1, fig.3 to be placed on single pages to simplify
readability.


=A0 =A0 This is a fine-tuning that shall be done with the RFC-editor. In the
=A0 =A0 process of RFC-editing, the boilerplate will change and so will the=
=A0 =A0 positioning of floating text and figures.

=A0 =A0 =A0 =A0 Consistently use re-attach and re-distribute _or_ reattach = and
=A0 =A0 =A0 =A0 redistribute, respectively, throughout document.
=A0 =A0 =A0 =A0 Is there any implicit meaning of Proxy with respect to prox= y?
=A0 =A0 =A0 =A0 Also MLD Proxy and MLD proxy are both used throughout the =A0 =A0 =A0 =A0 document ...


=A0 =A0 Thanks ... this should be corrected, now.


=A0 =A0 =A0 =A0 p.1
=A0 =A0 =A0 =A0 =A0 =A0 =A0optimizations for synchronizing PMIPv6 with PIM,= as
well as
=A0 =A0 =A0 =A0 a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0function for MLD Proxies defined.
=A0 =A0 =A0 =A0 =3D> =A0 optimizations for synchronizing PMIPv6 with PIM= , as
well as
=A0 =A0 =A0 =A0 a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0function for MLD Proxies are defined.


=A0 =A0 Thanks, corrected.

=A0 =A0 =A0 =A0 p.3
=A0 =A0 =A0 =A0 Such approaches (partially) follow the
=A0 =A0 =A0 =A0 =A0 =A0 =A0business model of providing multicast data servi= ces in
=A0 =A0 =A0 =A0 parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0PMIPv6 unicast routing.
=A0 =A0 =A0 =A0 =3D=3D> shouldn't one or more references be added he= re such as to
=A0 =A0 =A0 =A0 [I-D.ietf-multimob-pmipv6-__ropt],
=A0 =A0 =A0 =A0 draft-ietf-multimob-fmipv6-__pfmipv6-multicast,
=A0 =A0 =A0 =A0 draft-ietf-multimob-handover-__optimization =A0...?<= br>

=A0 =A0 Yes, good point: It's added now.

=A0 =A0 =A0 =A0 needs of receptive use cases
=A0 =A0 =A0 =A0 =3D> needs of applications for mobile multicast receptio= n of
=A0 =A0 =A0 =A0 content from few and mainly fixed content sources

=A0 =A0 =A0 =A0 p.5

=A0 =A0 =A0 =A0 A multicast unaware MAG would simply discard these packets = in
=A0 =A0 =A0 =A0 =A0 =A0 =A0the absence of a multicast routing information b= ase
(MRIB).
=A0 =A0 =A0 =A0 =3D=3D> shouldn't one add more information about MRI= Bs introduced
=A0 =A0 =A0 =A0 here for non-multicast aware readers such as: Such tables =A0 =A0 =A0 =A0 similar to MFIBs mentioned in RFC 6224 ensure that the
router is
=A0 =A0 =A0 =A0 able to correctly route/forward packets with multicast
addresses
=A0 =A0 =A0 =A0 as destinations .


=A0 =A0 O.K. - we've added a brief explanatory insert ... even though I=
=A0 =A0 believe that a mulitcast unaware reader will not succeed in taking<= br> =A0 =A0 profit from this document ;)


=A0 =A0 =A0 =A0 In case of a handover, the MN (unaware of IP mobility)
=A0 =A0 =A0 =A0 =3D> In case of a handover, the MN (being unaware of IP = mobility)


=A0 =A0 O.K., fixed.

=A0 =A0 =A0 =A0 as soon as network connectivity is
=A0 =A0 =A0 =A0 =A0 =A0 =A0reconfigured
=A0 =A0 =A0 =A0 =3D> as soon as network connectivity is
=A0 =A0 =A0 =A0 =A0 =A0 =A0re-established

=A0 =A0 O.K., fixed.


=A0 =A0 =A0 =A0 p.7
=A0 =A0 =A0 =A0 multicast data is =3D> multicast data are


=A0 =A0 Mhmm, my dictionary says "data is" ... "data" i= s a singular term
=A0 =A0 that subsumes (uncountable) plural ...


=A0 =A0 =A0 =A0 p.8
=A0 =A0 =A0 =A0 In addition, an LMA serving as PIM Designated Router is
connected
=A0 =A0 =A0 =A0 =3D> =A0In addition, an LMA serving as PIM Designated Ro= uter
(DR) is
=A0 =A0 =A0 =A0 connected


=A0 =A0 O.K., fixed.

=A0 =A0 =A0 =A0 incoming interface validation is only performed by RPF
=A0 =A0 =A0 =A0 =A0 =A0 =A0checks
=A0 =A0 =A0 =A0 =3D> incoming interface validation is only performed by = RPF
=A0 =A0 =A0 =A0 (Reverse Path Forwarding)
=A0 =A0 =A0 =A0 =A0 =A0 =A0checks


=A0 =A0 O.K., fixed.

=A0 =A0 =A0 =A0 Notably, running BIDIR PIM [RFC5015] on LMAs remains robust=
with
=A0 =A0 =A0 =A0 =A0 =A0 =A0respect to source location and does not require = special
=A0 =A0 =A0 =A0 =A0 =A0 =A0configurations or state management for sources.<= br> =A0 =A0 =A0 =A0 =3D=3D> Wouldn't it make sense to add a reason for t= his, e.g.
=A0 =A0 =A0 =A0 ... since BIDIR PIM automatically builds trees to allow
=A0 =A0 =A0 =A0 multicast data to be natively forwarded from sources to
=A0 =A0 =A0 =A0 receivers without requiring source-specific information ...=
=A0 =A0 =A0 =A0 On the other hand a reference to sect. 4.4 might be perhaps=
=A0 =A0 =A0 =A0 misleading here since this section is not on direct multica= st
=A0 =A0 =A0 =A0 routing?!


=A0 =A0 This is about the nature of BIDIR-PIM. The reason for this property=
=A0 =A0 is the bidirectional use of a static (=3D source-independent)
spanning
=A0 =A0 tree ... but explaining the ideas behind BIDIR-PIM may really go too
=A0 =A0 far here ... if readers haven't heard about BIDIR-PIM, the shou= ld
=A0 =A0 look up the reference.


=A0 =A0 =A0 =A0 an IGMP proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0function needs to be deployed at MAGs in exactly= the same
=A0 =A0 =A0 =A0 way as for
=A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6.
=A0 =A0 =A0 =A0 =3D> an IGMP proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0function needs to be deployed at MAGs in exactly= the same
=A0 =A0 =A0 =A0 way as is done for an MLD proxy for
=A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6.

=A0 =A0 =A0 =A0 p.9
=A0 =A0 =A0 =A0 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
=A0 =A0 =A0 =A0 =3D> For a dual-stack IPv4/IPv6 access network, the MAG = proxy
=A0 =A0 =A0 =A0 instances (i.e. IPMP/MLD proxy functions)

=A0 =A0 =A0 =A0 In the following, efficiency-related issues remain.
=A0 =A0 =A0 =A0 =3D> In the following, efficiency-related issues which r= emain
=A0 =A0 =A0 =A0 unsolved within the above defined base PMIPv6 multicast sou= rce
=A0 =A0 =A0 =A0 support are described.


=A0 =A0 Here, we would prefer the shorter forms.

=A0 =A0 =A0 =A0 p.11
=A0 =A0 =A0 =A0 upstream will lead traffic into the multicast infrastructur= e
=A0 =A0 =A0 =A0 =3D> =A0upstream will transfer traffic into the multicas= t
infrastructure


=A0 =A0 o.k.

=A0 =A0 =A0 =A0 p.12
=A0 =A0 =A0 =A0 configurations have completed =3D> configurations have b= een
completed


=A0 =A0 o.k.

=A0 =A0 =A0 =A0 traffic from the mobile source continues to be transmitted = via
the
=A0 =A0 =A0 =A0 =A0 =A0 =A0same next-hop router using the same source addre= ss
=A0 =A0 =A0 =A0 =3D> =A0traffic from the mobile source continues to be t= ransmitted
=A0 =A0 =A0 =A0 via the
=A0 =A0 =A0 =A0 =A0 =A0 =A0same next-hop multicast router using the same so= urce
address


=A0 =A0 o.k.

=A0 =A0 =A0 =A0 by aggregating proxies on a lower layer.
=A0 =A0 =A0 =A0 =3D=3D> please clarify: what layer exactly is proposed? = PIM DR at
MAGs?


=A0 =A0 A lower layer is meant in the (OSI) layered model: Layer 2 or
below.

=A0 =A0 =A0 =A0 =A0 =A0 in the access network for providing multicast servi= ces in
=A0 =A0 =A0 =A0 parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0unicast routes.
=A0 =A0 =A0 =A0 =3D> =A0in the access network for providing multicast se= rvices in
=A0 =A0 =A0 =A0 parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0unicast routes ( see Fig. 3(b)).


=A0 =A0 O.K.

=A0 =A0 =A0 =A0 p.13
=A0 =A0 =A0 =A0 =A0 =A0 The following information is needed for all phases = of PIM.
=A0 =A0 =A0 =A0 =3D> =A0The following information is needed for all thre= e phases of
=A0 =A0 =A0 =A0 PIM as outlined in [RFC4601].


=A0 =A0 O.K.

=A0 =A0 =A0 =A0 P.14
=A0 =A0 =A0 =A0 configured to not initiated (S,G) shortest path tress for mobile
=A0 =A0 =A0 =A0 =3D> configured to not initiated (S,G) shortest path tre= es for
mobile


=A0 =A0 Thanks, o.k.

=A0 =A0 =A0 =A0 mobile source. =A0This tree can be of lesser routing effici= ency
than
=A0 =A0 =A0 =A0 =3D> mobile source. =A0This tree can be of lower routing=
efficiency than


=A0 =A0 o.k.

=A0 =A0 =A0 =A0 In
=A0 =A0 =A0 =A0 =A0 =A0 =A0response, the PIM RP will recognize the known so= urce at a
new
=A0 =A0 =A0 =A0 =A0 =A0 =A0(tunnel) interface immediately responds with a r= egister
stop.
=A0 =A0 =A0 =A0 =3D> In
=A0 =A0 =A0 =A0 =A0 =A0 =A0response, the PIM RP will recognize the known so= urce at a
new
=A0 =A0 =A0 =A0 =A0 =A0 =A0(tunnel) interface and thus (?) immediately resp= ond with a
=A0 =A0 =A0 =A0 register stop.


=A0 =A0 O.k., fixed.

=A0 =A0 =A0 =A0 As the
=A0 =A0 =A0 =A0 =A0 =A0 =A0RP had joined the shortest path tree to receive = from the
=A0 =A0 =A0 =A0 source via
=A0 =A0 =A0 =A0 =A0 =A0 =A0the LMA,
=A0 =A0 =A0 =A0 =3D>As the
=A0 =A0 =A0 =A0 =A0 =A0 =A0RP has joined the shortest path tree to receive = data from
=A0 =A0 =A0 =A0 the source via
=A0 =A0 =A0 =A0 =A0 =A0 =A0the LMA,


=A0 =A0 Meanwhile replaced.

=A0 =A0 =A0 =A0 the LMA, it will see an RPF change when data arrives at a n= ew
=A0 =A0 =A0 =A0 =3D> the LMA, it will see an RPF change when data arrive= at a new


=A0 =A0 s.o.

=A0 =A0 =A0 =A0 In response to an exceeded threshold of packet transmission= ,
DRs of
=A0 =A0 =A0 =A0 =A0 =A0 =A0receivers eventually will initiated a source-spe= cific
Join for
=A0 =A0 =A0 =A0 =3D> In response to an exceeded threshold of packet tran= smission,
=A0 =A0 =A0 =A0 DRs of
=A0 =A0 =A0 =A0 =A0 =A0 =A0receivers eventually will initiate a source-spec= ific Join
for


=A0 =A0 Thanks, fixed.

=A0 =A0 =A0 =A0 this (S,G) tree will range from
=A0 =A0 =A0 =A0 =A0 =A0 =A0the receiving DR via the (stable) LMA, the LMA-M= AG tunnel
=A0 =A0 =A0 =A0 to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0mobile source
=A0 =A0 =A0 =A0 =3D>
=A0 =A0 =A0 =A0 this (S,G) tree will range from
=A0 =A0 =A0 =A0 =A0 =A0 =A0the receiving DR via the (stable) LMA, the LMA-M= AG tunnel,
=A0 =A0 =A0 =A0 and the serving MAG to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0mobile source (described from leave to root?)

=A0 =A0 o.k.

=A0 =A0 =A0 =A0 This tree is of higher routing efficiency than
=A0 =A0 =A0 =A0 established in the previous phase two
=A0 =A0 =A0 =A0 =3D>
=A0 =A0 =A0 =A0 This tree is of higher routing efficiency than
=A0 =A0 =A0 =A0 =A0 =A0that established in the previous phase two


=A0 =A0 thanks, o.k.

=A0 =A0 =A0 =A0 p.15
=A0 =A0 =A0 =A0 via the source register tunnel. =A0Tree mainenance eventual= ly
=A0 =A0 =A0 =A0 triggered
=A0 =A0 =A0 =A0 =3D> via the source register tunnel. =A0Tree maintenance= eventually
=A0 =A0 =A0 =A0 triggered


=A0 =A0 Thanks, o.k.

=A0 =A0 =A0 =A0 p.16
=A0 =A0 =A0 =A0 =A0 =A0 BIDIR-PIM MAY be deployed in the access network =3D= >
=A0 =A0 =A0 =A0 =A0 BIDIR-PIM [RFC5015] MAY be deployed in the access netwo= rk


=A0 =A0 Ref has been provided before.

=A0 =A0 =A0 =A0 remain uneffected by node mobility =3D> remain unaffecte= d by node
=A0 =A0 =A0 =A0 mobility


=A0 =A0 Thanks, fixed.

=A0 =A0 =A0 =A0 spanning group tree =3D> spanning tree for the multicast= group
=A0 =A0 =A0 =A0 /multicast spanning tree


=A0 =A0 o.k., thanks.

=A0 =A0 =A0 =A0 p.17
=A0 =A0 =A0 =A0 document. =A0To overcome these deficits, an optimized appro= ach to
=A0 =A0 =A0 =A0 =3D=3D> AFAIU it does mainly cover deficits mentioned in= sect.
4, if
=A0 =A0 =A0 =A0 also those inefficiencies described in 3.2.5 are tackled th= is
=A0 =A0 =A0 =A0 should be explained


=A0 =A0 Actually, the main concerns that are addressed in this peering
=A0 =A0 approach are from section 3.2.5, namely the parallel proxy
=A0 =A0 instances, which route via an LMA.

=A0 =A0 We've added text to make this clearer.


=A0 =A0 =A0 =A0 Following different techniques, these requirements are met = in
the
=A0 =A0 =A0 =A0 =A0 =A0 =A0following solutions.
=A0 =A0 =A0 =A0 =3D=3D> to me it seems to be one solution only (peering = between MLD
=A0 =A0 =A0 =A0 proxies) adapted to several multicast protocol implementati= ons
=A0 =A0 =A0 =A0 for ASM and SSM


=A0 =A0 Yes, the original text covered also the multiple-upstream proxy, =A0 =A0 which moved to the appendix now. The text has been corrected now.
=A0 =A0 =A0 =A0 but provide superior performance in the presence of source-=
=A0 =A0 =A0 =A0 =A0 =A0 =A0specific signaling (IGMPv3/MLDv2).
=A0 =A0 =A0 =A0 =3D=3D> Wouldn't a reference to RFC 4604 ("Usin= g Internet Group
=A0 =A0 =A0 =A0 Management Protocol Version 3 (IGMPv3) and Multicast Listen= er
=A0 =A0 =A0 =A0 Discovery Protocol Version 2 (MLDv2) for Source-Specific =A0 =A0 =A0 =A0 Multicast") make sense or be helpful here?


=A0 =A0 O.k., we've added this.


=A0 =A0 =A0 =A0 p.18
=A0 =A0 =A0 =A0 This filter base Must be updated, if and =3D> This filte= r base
=A0 =A0 =A0 =A0 MUST be updated, if and


=A0 =A0 thanks, fixed.

=A0 =A0 =A0 =A0 In
=A0 =A0 =A0 =A0 =A0 =A0 =A0addition, local multicast packets are transferre= d
=A0 =A0 =A0 =A0 =3D>
=A0 =A0 =A0 =A0 In
=A0 =A0 =A0 =A0 =A0 =A0 =A0addition, multicast packets from locally attache= d sources
=A0 =A0 =A0 =A0 are transferred
=A0 =A0 =A0 =A0 or:
=A0 =A0 =A0 =A0 =A0 =A0In addition, such locally arriving multicast packets= are
=A0 =A0 =A0 =A0 transferred


=A0 =A0 O.k., reworded.

=A0 =A0 =A0 =A0 p.19
=A0 =A0 =A0 =A0 6. =A0IANA Considerations
=A0 =A0 =A0 =A0 =A0 =A0 =A0TODO.
=A0 =A0 =A0 =A0 =3D=3D> to me there seem to be no IANA activities arisin= g from the
=A0 =A0 =A0 =A0 proposed protocol modifications, right?


=A0 =A0 Yes.

=A0 =A0 =A0 =A0 p.20
=A0 =A0 =A0 =A0 the PMIPv6 domain will not actively terminate group members= hip
prior
=A0 =A0 =A0 =A0 =A0 =A0 =A0to departure.
=A0 =A0 =A0 =A0 =3D>
=A0 =A0 =A0 =A0 the PMIPv6 domain will in general not actively terminate gr= oup
=A0 =A0 =A0 =A0 membership prior
=A0 =A0 =A0 =A0 =A0 =A0 =A0to departure.


=A0 =A0 o.k.

=A0 =A0 =A0 =A0 p.22
=A0 =A0 =A0 =A0 but alternate configuriations =3D> but alternate configu= rations

=A0 =A0 =A0 =A0 a state decomposition , if needed =3D> a state decomposi= tion, if
=A0 =A0 =A0 =A0 needed...


=A0 =A0 Thanks, fixed.

=A0 =A0 =A0 =A0 Hope this helps.


=A0 =A0 Yes, thanks a lot for this detailed review!

=A0 =A0 Best wishes,

=A0 =A0 Thomas


=A0 =A0 =A0 =A0 -----Original Message-----
=A0 =A0 =A0 =A0 From: multimob-bounces@ietf.org
=A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.org>
=A0 =A0 =A0 =A0 [mailto:multimob-bounces@ietf.__org
=A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.org>] On Behalf Of
=A0 =A0 =A0 =A0 internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
=A0 =A0 =A0 =A0 Sent: Samstag, 13. Juli 2013 00:50
=A0 =A0 =A0 =A0 To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
=A0 =A0 =A0 =A0 Cc: = multimob@ietf.org <mailto:multimob@ietf.org>
=A0 =A0 =A0 =A0 Subject: [multimob] I-D Action:
=A0 =A0 =A0 =A0 draft-ietf-multimob-pmipv6-__source-04.txt


=A0 =A0 =A0 =A0 A New Internet-Draft is available from the on-line
=A0 =A0 =A0 =A0 Internet-Drafts directories.
=A0 =A0 =A0 =A0 =A0 =A0This draft is a work item of the Multicast Mobility = Working
=A0 =A0 =A0 =A0 Group of the IETF.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Mobile Multi= cast Sender Support in
=A0 =A0 =A0 =A0 Proxy Mobile IPv6 (PMIPv6) Domains
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Thomas C. Schmid= t
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shu= ai Gao
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hon= g-Ke Zhang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mat= thias Waehlisch
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0:
=A0 =A0 =A0 =A0 draft-ietf-multimob-pmipv6-__source-04.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 24
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-12=

=A0 =A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0Multicast communication can be enabled in Proxy = Mobile
IPv6
=A0 =A0 =A0 =A0 domains
=A0 =A0 =A0 =A0 =A0 =A0 =A0via the Local Mobility Anchors by deploying MLD = Proxy
=A0 =A0 =A0 =A0 functions at
=A0 =A0 =A0 =A0 =A0 =A0 =A0Mobile Access Gateways, via a direct traffic dis= tribution
=A0 =A0 =A0 =A0 within an
=A0 =A0 =A0 =A0 =A0 =A0 =A0ISP's access network, or by selective route = optimization
=A0 =A0 =A0 =A0 schemes.
=A0 =A0 =A0 =A0 =A0 =A0 =A0This document describes the support of mobile mu= lticast
=A0 =A0 =A0 =A0 senders in
=A0 =A0 =A0 =A0 =A0 =A0 =A0Proxy Mobile IPv6 domains for all three scenario= s.
Protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0optimizations for synchronizing PMIPv6 with PIM,= as
well as
=A0 =A0 =A0 =A0 a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0function for MLD Proxies defined. =A0Mobile sour= ces always
remain
=A0 =A0 =A0 =A0 =A0 =A0 =A0agnostic of multicast mobility operations.



=A0 =A0 =A0 =A0 The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/__doc/draft-i= etf-multimob-__pmipv6-source

<https://datatracker.ietf.org/doc/draft-iet= f-multimob-pmipv6-source>

=A0 =A0 =A0 =A0 There's also a htmlized version available at:

http://tools.ietf.org/html/__draft-ietf-multi= mob-pmipv6-__source-04

<http://tools.ietf.org/html/draft-ietf-multimo= b-pmipv6-source-04>

=A0 =A0 =A0 =A0 A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?__url2=3D= draft-ietf-multimob-__pmipv6-source-04



<http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-multimob-pmipv6-source-04>


=A0 =A0 =A0 =A0 Internet-Drafts are also available by anonymous FTP at:
=A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-__drafts/
=A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/>

=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 multimob mailing list
=A0 =A0 =A0 =A0 mult= imob@ietf.org <mailto:multimob@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/multimob=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/multimob= >


=A0 =A0 --

=A0 =A0 Prof. Dr. Thomas C. Schmidt
=A0 =A0 =B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Berliner
=A0 =A0 Tor 7 =B0
=A0 =A0 =B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamb= urg,
=A0 =A0 Germany =B0
=A0 =A0 =B0 ht= tp://www.haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: =A0 =A0 +49-40-42875-8452 =B0
=A0 =A0 =B0 http://www.informatik.haw-__hamburg.de/~schmidt =A0 =A0 <http://www.informatik.haw-hamburg.de/~schmidt> = =A0 =A0Fax:
=A0 =A0 +49-40-42875-8409 =B0
=A0 =A0 _________________________________________________
=A0 =A0 multimob mailing list
=A0 =A0 multimob@iet= f.org <mailto:multimob@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/multimob
=A0 =A0 <https://www.ietf.org/mailman/listinfo/multimob>=






_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--089e011827ae963adf04e7b288e2-- From stig@venaas.com Tue Oct 1 14:17:48 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B80321F9F9D for ; Tue, 1 Oct 2013 14:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1fGp80ZKiYq for ; Tue, 1 Oct 2013 14:17:38 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1057021F9F86 for ; Tue, 1 Oct 2013 14:17:34 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-235.cisco.com [128.107.239.235]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8256F7F9A; Tue, 1 Oct 2013 23:17:32 +0200 (CEST) Message-ID: <524B3BE3.8010502@venaas.com> Date: Tue, 01 Oct 2013 14:17:23 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sarikaya@ieee.org References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com> <5249E105.8040405@informatik.haw-hamburg.de> <524B0301.8080301@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" , "Thomas C. Schmidt" , Behcet Sarikaya Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:17:48 -0000 On 10/1/2013 11:58 AM, Behcet Sarikaya wrote: > You mean a certain implementation has somehow foreseen these and acting > like this? No, it's per 4601, Stig > Otherwise you need to provide references. > > Regards, > > Behcet > > > On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas > wrote: > > Hi > > > On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote: > > Hi Stig, > > you're the PIM expert ... however, your statements confuse me. > > Event though the discussion does not matter to the source draft, > I would > like to clarify. Please see inline. > > On 30.09.2013 21:19, Stig Venaas wrote: > > Hi > > On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote: > > Dear Cong Liu, > > thanks for your feedback - please see inline. > > On 30.09.2013 08:47, Cong Liu wrote: > > Regarding this draft, I have the following comments > for consideration. > > P14: "This tree can be of lesser routing efficiency > than the PIM source > register tunnel established in phase one, but > provides the advantage of > immediate data delivery to receivers that share a > MAG with S." > - This sentence implicitly indicates that local > receivers sharing a MAG > with S cannot receive immediate multicast traffic > from the S in phase > one. In my opinion, even in phase one, the MAG > acting as the DR has the > related multicast state so that immediate data > delivery is possible. If > so, the sentence here is not appropriate. > > > This sentence actually refers to the building of an > (S,G)-Tree at the > end of PIM phase II. This tree follows reverse unicast > routes and thus > traverses the LMA-MAG tunnel - this is why it may be of > lower efficiency > than the forward (register) tunnel in phase I. > > What you are referring to is the question of > source-local traffic > distribution in PIM phase I. According to the way I > understand PIM-SM, > it does not distribute source-specific traffic locally > in Phase I. This > is because a local source S generates an (S,G)-State at > the sender's > local router (DR), but a receiver in ASM requires an > (*,G) service. > > > Traffic is distributed locally independent of the > registration process. > I assume you're talking about a source on one interface, and > receivers > on other interfaces on the same router? In that case for ASM > (receivers > joining a group, not specific sources), there would already be > (*,G)-join state, and packets from the source would both be > forwarded > on the joined interfaces and sent as PIM registers. > > > Mhmm ... this would mean that you have two feeds into the > distribution > tree: One rooted at the source (valid for local receivers), and one > rooted at the RP - at this stage, we are still in phase I. > > > If you're receiving packets from the source you're already on the > SPT and prune the source from the shared tree. > > > If (S,G) traffic were distributed locally, then the > required (*,G)-Join > to the RP would cause duplicate (S,G) traffic arriving > at the > source-local receiver. > > > No, that shouldn't happen. > > > How do you exclude? In phase I, all traffic is tunneled to the > RP and > the "path" from source to RP is not visible to the multicast > distribution system. The DR of the receiver, which happens to be > the DR > of one of the sources, would just initiate an (*,G) join towards > the RP > ... and all traffic tunneled to the RP would be distributed down > to the > receivers. > > > It would send a (*,G)-join with an (S,G) RPT prune. > > > Thus traffic from the (local) source would reach the (local) DR > and the > receiver twice ???? > > Looking at the spec in Section 3.1 of RFC4601: > > "At the end of phase one, multicast traffic is flowing > encapsulated to > the RP, and then natively over the RP tree to the > multicast > receivers." > > > That is sort of the general picture, but any receivers > connected to the > first hop router (and also later any routers on the path > from the FHR to > the RP) would receive packets before this. > > > I guess not: If multicast packets are tunneled in source register > packets, how can an intermediate router distribute them locally? I > suppose you are talking about PIM phase II, aren't you? > > > There are no strict phases like that. > > FHR would create (S,G)-state when the first packet arrives. The (S,G) > would have outgoing interfaces inherited from the (*,G) if there are > local receivers that joined G. In addition it sends registers. > > Later when the RP joins the SPT to receive packets natively (not > registers), you would create (S,G)-state and start receiving packets > on routers between FHR and the RP. Also these would immediately > send packets to local receivers (and pruning the source off the RPT), > rather than waiting to receive packets on the RPT. > > Stig > > > Cheers, > > Thomas > > > Some nits: > 1) The term "MLD proxy" and "MLD Proxy" should be > unified as MLD proxy > or MLD Proxy > 2) P14: This tree can be of lesser routing efficiency > - This tree can be of less routing efficiency > > > Thanks, it's fixed. > > Best regards, > > Thomas > > Thanks! > > Best Regards, > Cong Liu > > > 2013/9/30 Thomas C. Schmidt > > >> > > Hi Dirk, > > thanks again for your detailed comments. Please > see replies inline. > > On 26.08.2013 18 :29, > Dirk.von-Hugo@telekom.de > > > wrote: > > As promised at IETF-87 I did a review of > the source multicast > mobility draft and think the document is in > quite good shape. > > Being not the distinct expert in details of > multicast protocols > I am not sure to have understood everything > in detail, so > please > correct me and forgive misunderstandings ... > > The three scenarios described are > 1) the base solution with MLD proxies at > MAGs (and optionally > also at LMAs) (sect.3) > 2) direct routing with or without MLD > proxies at MAGs and with > native Multicast support at MAG level or > above via different > established Multicast protocols (sect.4) > 3) Routing optimization for direct routing > with MLD proxies at > MAGs (sect. 5) > Right? > > > Yes, this is it. > > IMHO from the abstract this is not easily > to see. > > > We have adjusted the abstract. In any case, it > explicitly addresses > (enumerates) the three scenarios mentioned abobe. > > I have some comments and suggestions to > increase > readability, in > addition to some nits found, given in the > following: > > Fig. 1, fig.3 to be placed on single pages > to simplify > readability. > > > This is a fine-tuning that shall be done with > the RFC-editor. In > the > process of RFC-editing, the boilerplate will > change and so will the > positioning of floating text and figures. > > Consistently use re-attach and > re-distribute _or_ reattach and > redistribute, respectively, throughout > document. > Is there any implicit meaning of Proxy with > respect to proxy? > Also MLD Proxy and MLD proxy are both used > throughout the > document ... > > > Thanks ... this should be corrected, now. > > > p.1 > optimizations for synchronizing PMIPv6 > with PIM, as > well as > a peering > function for MLD Proxies defined. > => optimizations for synchronizing PMIPv6 > with PIM, as > well as > a peering > function for MLD Proxies are defined. > > > Thanks, corrected. > > p.3 > Such approaches (partially) follow the > business model of providing multicast > data services in > parallel to > PMIPv6 unicast routing. > ==> shouldn't one or more references be > added here such as to > [I-D.ietf-multimob-pmipv6-____ropt], > > draft-ietf-multimob-fmipv6-____pfmipv6-multicast, > > draft-ietf-multimob-handover-____optimization ...? > > > Yes, good point: It's added now. > > needs of receptive use cases > => needs of applications for mobile > multicast reception of > content from few and mainly fixed content > sources > > p.5 > > A multicast unaware MAG would simply > discard these packets in > the absence of a multicast routing > information base > (MRIB). > ==> shouldn't one add more information > about MRIBs introduced > here for non-multicast aware readers such > as: Such tables > similar to MFIBs mentioned in RFC 6224 > ensure that the > router is > able to correctly route/forward packets > with multicast > addresses > as destinations . > > > O.K. - we've added a brief explanatory insert > ... even though I > believe that a mulitcast unaware reader will > not succeed in taking > profit from this document ;) > > > In case of a handover, the MN (unaware of > IP mobility) > => In case of a handover, the MN (being > unaware of IP mobility) > > > O.K., fixed. > > as soon as network connectivity is > reconfigured > => as soon as network connectivity is > re-established > > O.K., fixed. > > > p.7 > multicast data is => multicast data are > > > Mhmm, my dictionary says "data is" ... "data" > is a singular term > that subsumes (uncountable) plural ... > > > p.8 > In addition, an LMA serving as PIM > Designated Router is > connected > => In addition, an LMA serving as PIM > Designated Router > (DR) is > connected > > > O.K., fixed. > > incoming interface validation is only > performed by RPF > checks > => incoming interface validation is only > performed by RPF > (Reverse Path Forwarding) > checks > > > O.K., fixed. > > Notably, running BIDIR PIM [RFC5015] on > LMAs remains robust > with > respect to source location and does > not require special > configurations or state management for > sources. > ==> Wouldn't it make sense to add a reason > for this, e.g. > ... since BIDIR PIM automatically builds > trees to allow > multicast data to be natively forwarded > from sources to > receivers without requiring source-specific > information ... > On the other hand a reference to sect. 4.4 > might be perhaps > misleading here since this section is not > on direct multicast > routing?! > > > This is about the nature of BIDIR-PIM. The > reason for this property > is the bidirectional use of a static (= > source-independent) > spanning > tree ... but explaining the ideas behind > BIDIR-PIM may really go > too > far here ... if readers haven't heard about > BIDIR-PIM, the should > look up the reference. > > > an IGMP proxy > function needs to be deployed at MAGs > in exactly the same > way as for > IPv6. > => an IGMP proxy > function needs to be deployed at MAGs > in exactly the same > way as is done for an MLD proxy for > IPv6. > > p.9 > For a dual-stack IPv4/IPv6 access network, > the MAG proxy > instances > => For a dual-stack IPv4/IPv6 access > network, the MAG proxy > instances (i.e. IPMP/MLD proxy functions) > > In the following, efficiency-related issues > remain. > => In the following, efficiency-related > issues which remain > unsolved within the above defined base > PMIPv6 multicast source > support are described. > > > Here, we would prefer the shorter forms. > > p.11 > upstream will lead traffic into the > multicast infrastructure > => upstream will transfer traffic into the > multicast > infrastructure > > > o.k. > > p.12 > configurations have completed => > configurations have been > completed > > > o.k. > > traffic from the mobile source continues to > be transmitted via > the > same next-hop router using the same > source address > => traffic from the mobile source > continues to be transmitted > via the > same next-hop multicast router using > the same source > address > > > o.k. > > by aggregating proxies on a lower layer. > ==> please clarify: what layer exactly is > proposed? PIM DR at > MAGs? > > > A lower layer is meant in the (OSI) layered > model: Layer 2 or > below. > > in the access network for providing > multicast services in > parallel to > unicast routes. > => in the access network for providing > multicast services in > parallel to > unicast routes ( see Fig. 3(b)). > > > O.K. > > p.13 > The following information is needed for > all phases of PIM. > => The following information is needed for > all three phases of > PIM as outlined in [RFC4601]. > > > O.K. > > P.14 > configured to not initiated (S,G) shortest > path tress for > mobile > => configured to not initiated (S,G) > shortest path trees for > mobile > > > Thanks, o.k. > > mobile source. This tree can be of lesser > routing efficiency > than > => mobile source. This tree can be of > lower routing > efficiency than > > > o.k. > > In > response, the PIM RP will recognize > the known source at a > new > (tunnel) interface immediately > responds with a register > stop. > => In > response, the PIM RP will recognize > the known source at a > new > (tunnel) interface and thus (?) > immediately respond with a > register stop. > > > O.k., fixed. > > As the > RP had joined the shortest path tree > to receive from the > source via > the LMA, > =>As the > RP has joined the shortest path tree > to receive data from > the source via > the LMA, > > > Meanwhile replaced. > > the LMA, it will see an RPF change when > data arrives at a new > => the LMA, it will see an RPF change when > data arrive at a new > > > s.o. > > In response to an exceeded threshold of > packet transmission, > DRs of > receivers eventually will initiated a > source-specific > Join for > => In response to an exceeded threshold of > packet transmission, > DRs of > receivers eventually will initiate a > source-specific Join > for > > > Thanks, fixed. > > this (S,G) tree will range from > the receiving DR via the (stable) LMA, > the LMA-MAG tunnel > to the > mobile source > => > this (S,G) tree will range from > the receiving DR via the (stable) LMA, > the LMA-MAG tunnel, > and the serving MAG to the > mobile source (described from leave to > root?) > > > o.k. > > This tree is of higher routing efficiency than > established in the previous phase two > => > This tree is of higher routing efficiency than > that established in the previous phase two > > > thanks, o.k. > > p.15 > via the source register tunnel. Tree > mainenance eventually > triggered > => via the source register tunnel. Tree > maintenance eventually > triggered > > > Thanks, o.k. > > p.16 > BIDIR-PIM MAY be deployed in the access > network => > BIDIR-PIM [RFC5015] MAY be deployed in > the access network > > > Ref has been provided before. > > remain uneffected by node mobility => > remain unaffected by node > mobility > > > Thanks, fixed. > > spanning group tree => spanning tree for > the multicast group > /multicast spanning tree > > > o.k., thanks. > > p.17 > document. To overcome these deficits, an > optimized approach to > ==> AFAIU it does mainly cover deficits > mentioned in sect. > 4, if > also those inefficiencies described in > 3.2.5 are tackled this > should be explained > > > Actually, the main concerns that are addressed > in this peering > approach are from section 3.2.5, namely the > parallel proxy > instances, which route via an LMA. > > We've added text to make this clearer. > > > Following different techniques, these > requirements are met in > the > following solutions. > ==> to me it seems to be one solution only > (peering between MLD > proxies) adapted to several multicast > protocol implementations > for ASM and SSM > > > Yes, the original text covered also the > multiple-upstream proxy, > which moved to the appendix now. The text has > been corrected now. > > but provide superior performance in the > presence of source- > specific signaling (IGMPv3/MLDv2). > ==> Wouldn't a reference to RFC 4604 > ("Using Internet Group > Management Protocol Version 3 (IGMPv3) and > Multicast Listener > Discovery Protocol Version 2 (MLDv2) for > Source-Specific > Multicast") make sense or be helpful here? > > > O.k., we've added this. > > > p.18 > This filter base Must be updated, if and => > This filter base > MUST be updated, if and > > > thanks, fixed. > > In > addition, local multicast packets are > transferred > => > In > addition, multicast packets from > locally attached sources > are transferred > or: > In addition, such locally arriving > multicast packets are > transferred > > > O.k., reworded. > > p.19 > 6. IANA Considerations > TODO. > ==> to me there seem to be no IANA > activities arising from the > proposed protocol modifications, right? > > > Yes. > > p.20 > the PMIPv6 domain will not actively > terminate group membership > prior > to departure. > => > the PMIPv6 domain will in general not > actively terminate group > membership prior > to departure. > > > o.k. > > p.22 > but alternate configuriations => but > alternate configurations > > a state decomposition , if needed => a > state decomposition, if > needed... > > > Thanks, fixed. > > Hope this helps. > > > Yes, thanks a lot for this detailed review! > > Best wishes, > > Thomas > > > -----Original Message----- > From: multimob-bounces@ietf.org > > > > [mailto:multimob-bounces@ietf. > ____org > >] On Behalf Of > internet-drafts@ietf.org > > > > Sent: Samstag, 13. Juli 2013 00:50 > To: i-d-announce@ietf.org > > > > Cc: multimob@ietf.org > > > Subject: [multimob] I-D Action: > draft-ietf-multimob-pmipv6-____source-04.txt > > > A New Internet-Draft is available from the > on-line > Internet-Drafts directories. > This draft is a work item of the > Multicast Mobility Working > Group of the IETF. > > Title : Mobile Multicast > Sender Support in > Proxy Mobile IPv6 (PMIPv6) Domains > Author(s) : Thomas C. Schmidt > Shuai Gao > Hong-Ke Zhang > Matthias Waehlisch > Filename : > draft-ietf-multimob-pmipv6-____source-04.txt > Pages : 24 > Date : 2013-07-12 > > Abstract: > Multicast communication can be enabled > in Proxy Mobile > IPv6 > domains > via the Local Mobility Anchors by > deploying MLD Proxy > functions at > Mobile Access Gateways, via a direct > traffic distribution > within an > ISP's access network, or by selective > route optimization > schemes. > This document describes the support of > mobile multicast > senders in > Proxy Mobile IPv6 domains for all > three scenarios. > Protocol > optimizations for synchronizing PMIPv6 > with PIM, as > well as > a peering > function for MLD Proxies defined. > Mobile sources always > remain > agnostic of multicast mobility operations. > > > > The IETF datatracker status page for this > draft is: > > https://datatracker.ietf.org/____doc/draft-ietf-multimob-____pmipv6-source > > > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/____draft-ietf-multimob-pmipv6-____source-04 > > > > > > A diff from the previous version is > available at: > > http://www.ietf.org/rfcdiff?____url2=draft-ietf-multimob-____pmipv6-source-04 > > > > > > > > > Internet-Drafts are also available by > anonymous FTP at: > ftp://ftp.ietf.org/internet-____drafts/ > > > > > > ___________________________________________________ > 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 > > > From sarikaya2012@gmail.com Thu Oct 3 13:52:25 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EEC21F9642 for ; Thu, 3 Oct 2013 13:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7K3bwwhTITw for ; Thu, 3 Oct 2013 13:52:14 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86B1821F8E85 for ; Thu, 3 Oct 2013 13:37:22 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so2487420lbj.41 for ; Thu, 03 Oct 2013 13:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eB3gXUnyyCGQ3lUPoUGaL8refzud9jgxkQLvAwsu4JA=; b=NAzxLWrYF0JdijxkU4KJUlX6WRjBxRqCJ+vF9EQUwJt2f4Kp3vUxKmM0idv/afFa0i FMm1izIXAzQKeOuIOp8nL3baD8Yttw8ag60z65EqNDqyhvr7DLqMUDoyfauyd5usWQnJ 9Kr+SuyCRx2XvyZu5UECxSUQ8hGAId4iPL0LXUEWkX2EJRAfeU62hgwDf4FMylVMnCAF E75udFw67FMFel7WKzLx6SDQRrZLgsyFq3tvbSI4sStFRmth//oro0KAIJztX7sd/CYh 2XWNCXXCXjvHZ/O9go9T1MBhC3QfQh/Lw1Aqk/+4ABsFDNdwdAEfNHnhfK0c9UH+B0YK KHKQ== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr8377841lbb.0.1380832641199; Thu, 03 Oct 2013 13:37:21 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Thu, 3 Oct 2013 13:37:21 -0700 (PDT) In-Reply-To: <524B3BE3.8010502@venaas.com> References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com> <5249E105.8040405@informatik.haw-hamburg.de> <524B0301.8080301@venaas.com> <524B3BE3.8010502@venaas.com> Date: Thu, 3 Oct 2013 15:37:21 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: multipart/alternative; boundary=001a11c23c8812b66204e7dc277c Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:52:25 -0000 --001a11c23c8812b66204e7dc277c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2013 at 4:17 PM, Stig Venaas wrote: > On 10/1/2013 11:58 AM, Behcet Sarikaya wrote: > >> You mean a certain implementation has somehow foreseen these and acting >> like this? >> > > No, it's per 4601, > > Where in this 150 page document? A lot of people say PIM-BIDIR, RFC 5015, 43 pages, is better. Regards, Behcet > Stig > > Otherwise you need to provide references. >> >> Regards, >> >> Behcet >> >> >> On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas > > wrote: >> >> Hi >> >> >> On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote: >> >> Hi Stig, >> >> you're the PIM expert ... however, your statements confuse me. >> >> Event though the discussion does not matter to the source draft, >> I would >> like to clarify. Please see inline. >> >> On 30.09.2013 21:19, Stig Venaas wrote: >> >> Hi >> >> On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote: >> >> Dear Cong Liu, >> >> thanks for your feedback - please see inline. >> >> On 30.09.2013 08:47, Cong Liu wrote: >> >> Regarding this draft, I have the following comments >> for consideration. >> >> P14: "This tree can be of lesser routing efficiency >> than the PIM source >> register tunnel established in phase one, but >> provides the advantage of >> immediate data delivery to receivers that share a >> MAG with S." >> - This sentence implicitly indicates that local >> receivers sharing a MAG >> with S cannot receive immediate multicast traffic >> from the S in phase >> one. In my opinion, even in phase one, the MAG >> acting as the DR has the >> related multicast state so that immediate data >> delivery is possible. If >> so, the sentence here is not appropriate. >> >> >> This sentence actually refers to the building of an >> (S,G)-Tree at the >> end of PIM phase II. This tree follows reverse unicast >> routes and thus >> traverses the LMA-MAG tunnel - this is why it may be of >> lower efficiency >> than the forward (register) tunnel in phase I. >> >> What you are referring to is the question of >> source-local traffic >> distribution in PIM phase I. According to the way I >> understand PIM-SM, >> it does not distribute source-specific traffic locally >> in Phase I. This >> is because a local source S generates an (S,G)-State at >> the sender's >> local router (DR), but a receiver in ASM requires an >> (*,G) service. >> >> >> Traffic is distributed locally independent of the >> registration process. >> I assume you're talking about a source on one interface, and >> receivers >> on other interfaces on the same router? In that case for ASM >> (receivers >> joining a group, not specific sources), there would already = be >> (*,G)-join state, and packets from the source would both be >> forwarded >> on the joined interfaces and sent as PIM registers. >> >> >> Mhmm ... this would mean that you have two feeds into the >> distribution >> tree: One rooted at the source (valid for local receivers), and >> one >> rooted at the RP - at this stage, we are still in phase I. >> >> >> If you're receiving packets from the source you're already on the >> SPT and prune the source from the shared tree. >> >> >> If (S,G) traffic were distributed locally, then the >> required (*,G)-Join >> to the RP would cause duplicate (S,G) traffic arriving >> at the >> source-local receiver. >> >> >> No, that shouldn't happen. >> >> >> How do you exclude? In phase I, all traffic is tunneled to the >> RP and >> the "path" from source to RP is not visible to the multicast >> distribution system. The DR of the receiver, which happens to be >> the DR >> of one of the sources, would just initiate an (*,G) join towards >> the RP >> ... and all traffic tunneled to the RP would be distributed down >> to the >> receivers. >> >> >> It would send a (*,G)-join with an (S,G) RPT prune. >> >> >> Thus traffic from the (local) source would reach the (local) DR >> and the >> receiver twice ???? >> >> Looking at the spec in Section 3.1 of RFC4601: >> >> "At the end of phase one, multicast traffic is flowi= ng >> encapsulated to >> the RP, and then natively over the RP tree to the >> multicast >> receivers." >> >> >> That is sort of the general picture, but any receivers >> connected to the >> first hop router (and also later any routers on the path >> from the FHR to >> the RP) would receive packets before this. >> >> >> I guess not: If multicast packets are tunneled in source registe= r >> packets, how can an intermediate router distribute them locally?= I >> suppose you are talking about PIM phase II, aren't you? >> >> >> There are no strict phases like that. >> >> FHR would create (S,G)-state when the first packet arrives. The (S,G= ) >> would have outgoing interfaces inherited from the (*,G) if there are >> local receivers that joined G. In addition it sends registers. >> >> Later when the RP joins the SPT to receive packets natively (not >> registers), you would create (S,G)-state and start receiving packets >> on routers between FHR and the RP. Also these would immediately >> send packets to local receivers (and pruning the source off the RPT)= , >> rather than waiting to receive packets on the RPT. >> >> Stig >> >> >> Cheers, >> >> Thomas >> >> >> Some nits: >> 1) The term "MLD proxy" and "MLD Proxy" should be >> unified as MLD proxy >> or MLD Proxy >> 2) P14: This tree can be of lesser routing efficienc= y >> - This tree can be of less routing efficiency >> >> >> Thanks, it's fixed. >> >> Best regards, >> >> Thomas >> >> Thanks! >> >> Best Regards, >> Cong Liu >> >> >> 2013/9/30 Thomas C. Schmidt >> >> >> > >> >> >> >> >>> >> >> Hi Dirk, >> >> thanks again for your detailed comments. Please >> see replies inline. >> >> On 26.08.2013 18 :29, >> Dirk.von-Hugo@telekom.de >> >> > >> > >> >> >> wrote: >> >> As promised at IETF-87 I did a review of >> the source multicast >> mobility draft and think the document is in >> quite good shape. >> >> Being not the distinct expert in details of >> multicast protocols >> I am not sure to have understood everything >> in detail, so >> please >> correct me and forgive misunderstandings ..= . >> >> The three scenarios described are >> 1) the base solution with MLD proxies at >> MAGs (and optionally >> also at LMAs) (sect.3) >> 2) direct routing with or without MLD >> proxies at MAGs and with >> native Multicast support at MAG level or >> above via different >> established Multicast protocols (sect.4) >> 3) Routing optimization for direct routing >> with MLD proxies at >> MAGs (sect. 5) >> Right? >> >> >> Yes, this is it. >> >> IMHO from the abstract this is not easily >> to see. >> >> >> We have adjusted the abstract. In any case, it >> explicitly addresses >> (enumerates) the three scenarios mentioned abob= e. >> >> I have some comments and suggestions to >> increase >> readability, in >> addition to some nits found, given in the >> following: >> >> Fig. 1, fig.3 to be placed on single pages >> to simplify >> readability. >> >> >> This is a fine-tuning that shall be done with >> the RFC-editor. In >> the >> process of RFC-editing, the boilerplate will >> change and so will the >> positioning of floating text and figures. >> >> Consistently use re-attach and >> re-distribute _or_ reattach and >> redistribute, respectively, throughout >> document. >> Is there any implicit meaning of Proxy with >> respect to proxy? >> Also MLD Proxy and MLD proxy are both used >> throughout the >> document ... >> >> >> Thanks ... this should be corrected, now. >> >> >> p.1 >> optimizations for synchronizing PMIPv6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies defined. >> =3D> optimizations for synchronizing PMIP= v6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies are defined. >> >> >> Thanks, corrected. >> >> p.3 >> Such approaches (partially) follow the >> business model of providing multicast >> data services in >> parallel to >> PMIPv6 unicast routing. >> =3D=3D> shouldn't one or more references be >> added here such as to >> [I-D.ietf-multimob-pmipv6-____**ropt], >> >> draft-ietf-multimob-fmipv6-___**_pfmipv6-multicast, >> >> draft-ietf-multimob-handover-_**___optimization ...= ? >> >> >> >> Yes, good point: It's added now. >> >> needs of receptive use cases >> =3D> needs of applications for mobile >> multicast reception of >> content from few and mainly fixed content >> sources >> >> p.5 >> >> A multicast unaware MAG would simply >> discard these packets in >> the absence of a multicast routing >> information base >> (MRIB). >> =3D=3D> shouldn't one add more information >> about MRIBs introduced >> here for non-multicast aware readers such >> as: Such tables >> similar to MFIBs mentioned in RFC 6224 >> ensure that the >> router is >> able to correctly route/forward packets >> with multicast >> addresses >> as destinations . >> >> >> O.K. - we've added a brief explanatory insert >> ... even though I >> believe that a mulitcast unaware reader will >> not succeed in taking >> profit from this document ;) >> >> >> In case of a handover, the MN (unaware of >> IP mobility) >> =3D> In case of a handover, the MN (being >> unaware of IP mobility) >> >> >> O.K., fixed. >> >> as soon as network connectivity is >> reconfigured >> =3D> as soon as network connectivity is >> re-established >> >> O.K., fixed. >> >> >> p.7 >> multicast data is =3D> multicast data are >> >> >> Mhmm, my dictionary says "data is" ... "data" >> is a singular term >> that subsumes (uncountable) plural ... >> >> >> p.8 >> In addition, an LMA serving as PIM >> Designated Router is >> connected >> =3D> In addition, an LMA serving as PIM >> Designated Router >> (DR) is >> connected >> >> >> O.K., fixed. >> >> incoming interface validation is only >> performed by RPF >> checks >> =3D> incoming interface validation is only >> performed by RPF >> (Reverse Path Forwarding) >> checks >> >> >> O.K., fixed. >> >> Notably, running BIDIR PIM [RFC5015] on >> LMAs remains robust >> with >> respect to source location and does >> not require special >> configurations or state management for >> sources. >> =3D=3D> Wouldn't it make sense to add a rea= son >> for this, e.g. >> ... since BIDIR PIM automatically builds >> trees to allow >> multicast data to be natively forwarded >> from sources to >> receivers without requiring source-specific >> information ... >> On the other hand a reference to sect. 4.4 >> might be perhaps >> misleading here since this section is not >> on direct multicast >> routing?! >> >> >> This is about the nature of BIDIR-PIM. The >> reason for this property >> is the bidirectional use of a static (=3D >> source-independent) >> spanning >> tree ... but explaining the ideas behind >> BIDIR-PIM may really go >> too >> far here ... if readers haven't heard about >> BIDIR-PIM, the should >> look up the reference. >> >> >> an IGMP proxy >> function needs to be deployed at MAGs >> in exactly the same >> way as for >> IPv6. >> =3D> an IGMP proxy >> function needs to be deployed at MAGs >> in exactly the same >> way as is done for an MLD proxy for >> IPv6. >> >> p.9 >> For a dual-stack IPv4/IPv6 access network, >> the MAG proxy >> instances >> =3D> For a dual-stack IPv4/IPv6 access >> network, the MAG proxy >> instances (i.e. IPMP/MLD proxy functions) >> >> In the following, efficiency-related issues >> remain. >> =3D> In the following, efficiency-related >> issues which remain >> unsolved within the above defined base >> PMIPv6 multicast source >> support are described. >> >> >> Here, we would prefer the shorter forms. >> >> p.11 >> upstream will lead traffic into the >> multicast infrastructure >> =3D> upstream will transfer traffic into t= he >> multicast >> infrastructure >> >> >> o.k. >> >> p.12 >> configurations have completed =3D> >> configurations have been >> completed >> >> >> o.k. >> >> traffic from the mobile source continues to >> be transmitted via >> the >> same next-hop router using the same >> source address >> =3D> traffic from the mobile source >> continues to be transmitted >> via the >> same next-hop multicast router using >> the same source >> address >> >> >> o.k. >> >> by aggregating proxies on a lower layer. >> =3D=3D> please clarify: what layer exactly = is >> proposed? PIM DR at >> MAGs? >> >> >> A lower layer is meant in the (OSI) layered >> model: Layer 2 or >> below. >> >> in the access network for providing >> multicast services in >> parallel to >> unicast routes. >> =3D> in the access network for providing >> multicast services in >> parallel to >> unicast routes ( see Fig. 3(b)). >> >> >> O.K. >> >> p.13 >> The following information is needed for >> all phases of PIM. >> =3D> The following information is needed f= or >> all three phases of >> PIM as outlined in [RFC4601]. >> >> >> O.K. >> >> P.14 >> configured to not initiated (S,G) shortest >> path tress for >> mobile >> =3D> configured to not initiated (S,G) >> shortest path trees for >> mobile >> >> >> Thanks, o.k. >> >> mobile source. This tree can be of lesser >> routing efficiency >> than >> =3D> mobile source. This tree can be of >> lower routing >> efficiency than >> >> >> o.k. >> >> In >> response, the PIM RP will recognize >> the known source at a >> new >> (tunnel) interface immediately >> responds with a register >> stop. >> =3D> In >> response, the PIM RP will recognize >> the known source at a >> new >> (tunnel) interface and thus (?) >> immediately respond with a >> register stop. >> >> >> O.k., fixed. >> >> As the >> RP had joined the shortest path tree >> to receive from the >> source via >> the LMA, >> =3D>As the >> RP has joined the shortest path tree >> to receive data from >> the source via >> the LMA, >> >> >> Meanwhile replaced. >> >> the LMA, it will see an RPF change when >> data arrives at a new >> =3D> the LMA, it will see an RPF change whe= n >> data arrive at a new >> >> >> s.o. >> >> In response to an exceeded threshold of >> packet transmission, >> DRs of >> receivers eventually will initiated a >> source-specific >> Join for >> =3D> In response to an exceeded threshold o= f >> packet transmission, >> DRs of >> receivers eventually will initiate a >> source-specific Join >> for >> >> >> Thanks, fixed. >> >> this (S,G) tree will range from >> the receiving DR via the (stable) LMA, >> the LMA-MAG tunnel >> to the >> mobile source >> =3D> >> this (S,G) tree will range from >> the receiving DR via the (stable) LMA, >> the LMA-MAG tunnel, >> and the serving MAG to the >> mobile source (described from leave to >> root?) >> >> >> o.k. >> >> This tree is of higher routing efficiency >> than >> established in the previous phase two >> =3D> >> This tree is of higher routing efficiency >> than >> that established in the previous phase t= wo >> >> >> thanks, o.k. >> >> p.15 >> via the source register tunnel. Tree >> mainenance eventually >> triggered >> =3D> via the source register tunnel. Tree >> maintenance eventually >> triggered >> >> >> Thanks, o.k. >> >> p.16 >> BIDIR-PIM MAY be deployed in the access >> network =3D> >> BIDIR-PIM [RFC5015] MAY be deployed in >> the access network >> >> >> Ref has been provided before. >> >> remain uneffected by node mobility =3D> >> remain unaffected by node >> mobility >> >> >> Thanks, fixed. >> >> spanning group tree =3D> spanning tree for >> the multicast group >> /multicast spanning tree >> >> >> o.k., thanks. >> >> p.17 >> document. To overcome these deficits, an >> optimized approach to >> =3D=3D> AFAIU it does mainly cover deficits >> mentioned in sect. >> 4, if >> also those inefficiencies described in >> 3.2.5 are tackled this >> should be explained >> >> >> Actually, the main concerns that are addressed >> in this peering >> approach are from section 3.2.5, namely the >> parallel proxy >> instances, which route via an LMA. >> >> We've added text to make this clearer. >> >> >> Following different techniques, these >> requirements are met in >> the >> following solutions. >> =3D=3D> to me it seems to be one solution o= nly >> (peering between MLD >> proxies) adapted to several multicast >> protocol implementations >> for ASM and SSM >> >> >> Yes, the original text covered also the >> multiple-upstream proxy, >> which moved to the appendix now. The text has >> been corrected now. >> >> but provide superior performance in the >> presence of source- >> specific signaling (IGMPv3/MLDv2). >> =3D=3D> Wouldn't a reference to RFC 4604 >> ("Using Internet Group >> Management Protocol Version 3 (IGMPv3) and >> Multicast Listener >> Discovery Protocol Version 2 (MLDv2) for >> Source-Specific >> Multicast") make sense or be helpful here? >> >> >> O.k., we've added this. >> >> >> p.18 >> This filter base Must be updated, if and = =3D> >> This filter base >> MUST be updated, if and >> >> >> thanks, fixed. >> >> In >> addition, local multicast packets are >> transferred >> =3D> >> In >> addition, multicast packets from >> locally attached sources >> are transferred >> or: >> In addition, such locally arriving >> multicast packets are >> transferred >> >> >> O.k., reworded. >> >> p.19 >> 6. IANA Considerations >> TODO. >> =3D=3D> to me there seem to be no IANA >> activities arising from the >> proposed protocol modifications, right? >> >> >> Yes. >> >> p.20 >> the PMIPv6 domain will not actively >> terminate group membership >> prior >> to departure. >> =3D> >> the PMIPv6 domain will in general not >> actively terminate group >> membership prior >> to departure. >> >> >> o.k. >> >> p.22 >> but alternate configuriations =3D> but >> alternate configurations >> >> a state decomposition , if needed =3D> a >> state decomposition, if >> needed... >> >> >> Thanks, fixed. >> >> Hope this helps. >> >> >> Yes, thanks a lot for this detailed review! >> >> Best wishes, >> >> Thomas >> >> >> -----Original Message----- >> From: multimob-bounces@ietf.org >> >> > >> > >> >> >> [mailto:multimob-bounces@ietf. >> ____org >> > >>] >> On Behalf Of >> internet-drafts@ietf.org >> >> > >> > >> >> >> >> Sent: Samstag, 13. Juli 2013 00:50 >> To: i-d-announce@ietf.org >> >> > **> >> Cc: multimob@ietf.org >> > >> > >> Subject: [multimob] I-D Action: >> draft-ietf-multimob-pmipv6-___** >> _source-04.txt >> >> >> >> A New Internet-Draft is available from the >> on-line >> Internet-Drafts directories. >> This draft is a work item of the >> Multicast Mobility Working >> Group of the IETF. >> >> Title : Mobile Multicast >> Sender Support in >> Proxy Mobile IPv6 (PMIPv6) Domains >> Author(s) : Thomas C. Schmid= t >> Shuai Gao >> Hong-Ke Zhang >> Matthias >> Waehlisch >> Filename : >> draft-ietf-multimob-pmipv6-___** >> _source-04.txt >> >> Pages : 24 >> Date : 2013-07-12 >> >> Abstract: >> Multicast communication can be enabled >> in Proxy Mobile >> IPv6 >> domains >> via the Local Mobility Anchors by >> deploying MLD Proxy >> functions at >> Mobile Access Gateways, via a direct >> traffic distribution >> within an >> ISP's access network, or by selective >> route optimization >> schemes. >> This document describes the support of >> mobile multicast >> senders in >> Proxy Mobile IPv6 domains for all >> three scenarios. >> Protocol >> optimizations for synchronizing PMIPv6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies defined. >> Mobile sources always >> remain >> agnostic of multicast mobility >> operations. >> >> >> >> The IETF datatracker status page for this >> draft is: >> >> https://datatracker.ietf.org/_** >> ___doc/draft-ietf-multimob-___**_pmipv6-source >> > __doc/draft-ietf-multimob-__**pmipv6-source >> > >> >> >> > __doc/draft-ietf-multimob-__**pmipv6-source >> > doc/draft-ietf-multimob-**pmipv6-source >> >> >> >> There's also a htmlized version available a= t: >> >> http://tools.ietf.org/html/___** >> _draft-ietf-multimob-pmipv6-__**__source-04 >> > draft-ietf-multimob-pmipv6-__**source-04 >> > >> >> >> > draft-ietf-multimob-pmipv6-__**source-04 >> > draft-ietf-multimob-pmipv6-**source-04 >> >> >> >> A diff from the previous version is >> available at: >> >> http://www.ietf.org/rfcdiff?__** >> __url2=3Ddraft-ietf-multimob-___**_pmipv6-source-04 >> > _url2=3Ddraft-ietf-multimob-__**pmipv6-source-04 >> > >> >> >> >> >> > _url2=3Ddraft-ietf-multimob-__**pmipv6-source-04 >> > url2=3Ddraft-ietf-multimob-**pmipv6-source-04 >> >> >> >> >> Internet-Drafts are also available by >> anonymous FTP at: >> ftp://ftp.ietf.org/internet-__**__drafts/ >> >> > >> >> >> >> >> >> >> ______________________________**____________________= _ >> >> multimob mailing list >> multimob@ietf.org >> = > >> https://www.ietf.org/mailman/_**___listinfo/multimob= >> >> > >> >> >> >> >> >> >> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences >> Berliner >> Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Gro= up >> 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<= http://www.informatik.haw-____hamburg.de/~schmidt> >> >> > >> >> >> >> >> >> Fax: >> +49-40-42875-8409 =B0 >> ______________________________** >> _____________________ >> >> multimob mailing list >> multimob@ietf.org >> = > >> https://www.ietf.org/mailman/_**___listinfo/multimob= >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/multimob >> >> > >> >> >> > --001a11c23c8812b66204e7dc277c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 1, 2013 at 4:17 PM, Stig Venaas <<= a href=3D"mailto:stig@venaas.com" target=3D"_blank">stig@venaas.com>= wrote:
On 10/1/2013 11:58 AM, Beh= cet Sarikaya wrote:
You mean a certain implementation has somehow foreseen these and acting
like this?

No, it's per 4601,


Where in this 150 page document?
A lot of people say PIM-BIDIR, RFC 5015, 43 pages, is better.<= br>
Regards,

Behcet
Stig

Otherwise you need to provide references.

Regards,

Behcet


On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas <stig@venaas.com
<mailto:stig@venaas= .com>> wrote:

=A0 =A0 Hi


=A0 =A0 On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote:

=A0 =A0 =A0 =A0 Hi Stig,

=A0 =A0 =A0 =A0 you're the PIM expert ... however, your statements conf= use me.

=A0 =A0 =A0 =A0 Event though the discussion does not matter to the source d= raft,
=A0 =A0 =A0 =A0 I would
=A0 =A0 =A0 =A0 like to clarify. Please see inline.

=A0 =A0 =A0 =A0 On 30.09.2013 21:19, Stig Venaas wrote:

=A0 =A0 =A0 =A0 =A0 =A0 Hi

=A0 =A0 =A0 =A0 =A0 =A0 On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dear Cong Liu,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 thanks for your feedback - please see inlin= e.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 30.09.2013 08:47, Cong Liu wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regarding this draft, I have the fo= llowing comments
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for consideration.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 P14: "This tree can be of less= er routing efficiency
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 than the PIM source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 register tunnel established in phas= e one, but
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 provides the advantage of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 immediate data delivery to receiver= s that share a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MAG with S."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - This sentence implicitly indicate= s that local
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receivers sharing a MAG
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with S cannot receive immediate mul= ticast traffic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from the S in phase
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 one. In my opinion, even in phase o= ne, the MAG
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 acting as the DR has the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 related multicast state so that imm= ediate data
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 delivery is possible. If
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 so, the sentence here is not approp= riate.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This sentence actually refers to the buildi= ng of an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (S,G)-Tree at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end of PIM phase II. This tree follows reve= rse unicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 routes and thus
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 traverses the LMA-MAG tunnel - this is why = it may be of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lower efficiency
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 than the forward (register) tunnel in phase= I.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 What you are referring to is the question o= f
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source-local traffic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 distribution in PIM phase I. According to t= he way I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 understand =A0PIM-SM,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it does not distribute source-specific traf= fic locally
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in Phase I. This
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is because a local source S generates an (S= ,G)-State at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the sender's
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 local router (DR), but a receiver in ASM re= quires an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (*,G) service.


=A0 =A0 =A0 =A0 =A0 =A0 Traffic is distributed locally independent of the =A0 =A0 =A0 =A0 =A0 =A0 registration process.
=A0 =A0 =A0 =A0 =A0 =A0 I assume you're talking about a source on one i= nterface, and
=A0 =A0 =A0 =A0 =A0 =A0 receivers
=A0 =A0 =A0 =A0 =A0 =A0 on other interfaces on the same router? In that cas= e for ASM
=A0 =A0 =A0 =A0 =A0 =A0 (receivers
=A0 =A0 =A0 =A0 =A0 =A0 joining a group, not specific sources), there would= already be
=A0 =A0 =A0 =A0 =A0 =A0 (*,G)-join state, and packets from the source would= both be
=A0 =A0 =A0 =A0 =A0 =A0 forwarded
=A0 =A0 =A0 =A0 =A0 =A0 on the joined interfaces and sent as PIM registers.=


=A0 =A0 =A0 =A0 Mhmm ... this would mean that you have two feeds into the =A0 =A0 =A0 =A0 distribution
=A0 =A0 =A0 =A0 tree: One rooted at the source (valid for local receivers),= and one
=A0 =A0 =A0 =A0 rooted at the RP - at this stage, we are still in phase I.<= br>

=A0 =A0 If you're receiving packets from the source you're already = on the
=A0 =A0 SPT and prune the source from the shared tree.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If (S,G) traffic were distributed locally, = then the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 required (*,G)-Join
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to the RP would cause duplicate (S,G) traff= ic arriving
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source-local receiver.


=A0 =A0 =A0 =A0 =A0 =A0 No, that shouldn't happen.


=A0 =A0 =A0 =A0 How do you exclude? In phase I, all traffic is tunneled to = the
=A0 =A0 =A0 =A0 RP and
=A0 =A0 =A0 =A0 the "path" from source to RP is not visible to th= e multicast
=A0 =A0 =A0 =A0 distribution system. The DR of the receiver, which happens = to be
=A0 =A0 =A0 =A0 the DR
=A0 =A0 =A0 =A0 of one of the sources, would just initiate an (*,G) join to= wards
=A0 =A0 =A0 =A0 the RP
=A0 =A0 =A0 =A0 ... and all traffic tunneled to the RP would be distributed= down
=A0 =A0 =A0 =A0 to the
=A0 =A0 =A0 =A0 receivers.


=A0 =A0 It would send a (*,G)-join with an (S,G) RPT prune.


=A0 =A0 =A0 =A0 Thus traffic from the (local) source would reach the (local= ) DR
=A0 =A0 =A0 =A0 and the
=A0 =A0 =A0 =A0 receiver twice ????

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Looking at the spec in Section 3.1 of RFC46= 01:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "At the end of phase one, mult= icast traffic is flowing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 encapsulated to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the RP, and then natively over t= he RP tree to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receivers."


=A0 =A0 =A0 =A0 =A0 =A0 That is sort of the general picture, but any receiv= ers
=A0 =A0 =A0 =A0 =A0 =A0 connected to the
=A0 =A0 =A0 =A0 =A0 =A0 first hop router (and also later any routers on the= path
=A0 =A0 =A0 =A0 =A0 =A0 from the FHR to
=A0 =A0 =A0 =A0 =A0 =A0 the RP) would receive packets before this.


=A0 =A0 =A0 =A0 I guess not: If multicast packets are tunneled in source re= gister
=A0 =A0 =A0 =A0 packets, how can an intermediate router distribute them loc= ally? I
=A0 =A0 =A0 =A0 suppose you are talking about PIM phase II, aren't you?=


=A0 =A0 There are no strict phases like that.

=A0 =A0 FHR would create (S,G)-state when the first packet arrives. The (S,= G)
=A0 =A0 would have outgoing interfaces inherited from the (*,G) if there ar= e
=A0 =A0 local receivers that joined G. In addition it sends registers.

=A0 =A0 Later when the RP joins the SPT to receive packets natively (not =A0 =A0 registers), you would create (S,G)-state and start receiving packet= s
=A0 =A0 on routers between FHR and the RP. Also these would immediately
=A0 =A0 send packets to local receivers (and pruning the source off the RPT= ),
=A0 =A0 rather than waiting to receive packets on the RPT.

=A0 =A0 Stig


=A0 =A0 =A0 =A0 Cheers,

=A0 =A0 =A0 =A0 Thomas


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Some nits:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) The term "MLD proxy" a= nd "MLD Proxy" should be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unified as MLD proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 or MLD Proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) P14: This tree can be of lesser = routing efficiency
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - This tree can be of less routing = efficiency


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks, it's fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks!

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cong Liu


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2013/9/30 Thomas C. Schmidt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <schmidt@informatik.haw-__h= amburg.de
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:schmidt@informatik.ha= w-hamburg.de>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:schmidt@informatik.__haw-hamburg.de

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:schmidt@informatik.ha= w-hamburg.de>>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Dirk,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thanks again for your de= tailed comments. Please
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 see replies inline.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 26.08.2013 18 <t= el:26.08.2013%2018>:29,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dirk.von-Hugo@telekom.de
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:Dirk.von-Hugo@telekom.de&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:Dirk.von-Hugo@telekom.__de

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:Dirk.von-Hugo@telekom.de&g= t;> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0As promised at I= ETF-87 I did a review of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the source multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mobility draft a= nd think the document is in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 quite good shape.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Being not the di= stinct expert in details of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast protocols
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I am not sure to= have understood everything
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in detail, so
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 please
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0correct me and f= orgive misunderstandings ...

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The three scenar= ios described are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01) the base solu= tion with MLD proxies at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MAGs (and optionally
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0also at LMAs) (s= ect.3)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02) direct routin= g with or without MLD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 proxies at MAGs and with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0native Multicast= support at MAG level or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 above via different
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0established Mult= icast protocols (sect.4)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03) Routing optim= ization for direct routing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with MLD proxies at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MAGs (sect. 5) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Right?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, this is it.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IMHO from the ab= stract this is not easily
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to see.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We have adjusted the abs= tract. In any case, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 explicitly addresses
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(enumerates) the three s= cenarios mentioned abobe.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I have some comm= ents and suggestions to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 increase
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 readability, in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addition to some= nits found, given in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 following:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fig. 1, fig.3 to= be placed on single pages
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to simplify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 readability.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is a fine-tuning th= at shall be done with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the RFC-editor. In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of RFC-editing, = the boilerplate will
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 change and so will the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0positioning of floating = text and figures.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Consistently use= re-attach and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 re-distribute _or_ reattach and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0redistribute, re= spectively, throughout
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 document.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is there any imp= licit meaning of Proxy with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 respect to proxy?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Also MLD Proxy a= nd MLD proxy are both used
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 throughout the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0document ...


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks ... this should b= e corrected, now.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.1
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 optimiz= ations for synchronizing PMIPv6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with PIM, as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 well as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 functio= n for MLD Proxies defined.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 opti= mizations for synchronizing PMIPv6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with PIM, as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 well as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 functio= n for MLD Proxies are defined.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, corrected.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Such approaches = (partially) follow the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 busines= s model of providing multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data services in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PMIPv6 = unicast routing.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> shoul= dn't one or more references be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 added here such as to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[I-D.ietf-multim= ob-pmipv6-____ropt],

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-multimob-fmipv6-____pfmipv6-multicast,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-multimob-handover-____optimization =A0...?



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, good point: It'= s added now.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0needs of recepti= ve use cases
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> needs of= applications for mobile
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast reception of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0content from few= and mainly fixed content
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sources

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.5

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A multicast unaw= are MAG would simply
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 discard these packets in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the abs= ence of a multicast routing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information base
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (MRIB).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> shoul= dn't one add more information
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 about MRIBs introduced
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0here for non-mul= ticast aware readers such
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as: Such tables
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0similar to MFIBs= mentioned in RFC 6224
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ensure that the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 router is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0able to correctl= y route/forward packets
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addresses
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as destinations = .


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K. - we've added a= brief explanatory insert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... even though I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0believe that a mulitcast= unaware reader will
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not succeed in taking
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0profit from this documen= t ;)


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In case of a han= dover, the MN (unaware of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IP mobility)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> In case = of a handover, the MN (being
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unaware of IP mobility)


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K., fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as soon as netwo= rk connectivity is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reconfi= gured
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> as soon = as network connectivity is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 re-esta= blished

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K., fixed.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.7
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multicast data i= s =3D> multicast data are


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mhmm, my dictionary says= "data is" ... "data"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is a singular term
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that subsumes (uncountab= le) plural ...


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.8
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In addition, an = LMA serving as PIM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Designated Router is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 connected
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0In ad= dition, an LMA serving as PIM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Designated Router
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (DR) is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0connected


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K., fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incoming interfa= ce validation is only
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 performed by RPF
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 checks<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> incoming= interface validation is only
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 performed by RPF
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Reverse Path Fo= rwarding)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 checks<= br>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K., fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Notably, running= BIDIR PIM [RFC5015] on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LMAs remains robust
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 respect= to source location and does
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not require special
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 configu= rations or state management for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sources.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> Would= n't it make sense to add a reason
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for this, e.g.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... since BIDIR = PIM automatically builds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 trees to allow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multicast data t= o be natively forwarded
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from sources to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0receivers withou= t requiring source-specific
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information ...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On the other han= d a reference to sect. 4.4
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 might be perhaps
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0misleading here = since this section is not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on direct multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0routing?!


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is about the nature= of BIDIR-PIM. The
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reason for this property
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the bidirectional use= of a static (=3D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source-independent)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spanning
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tree ... but explaining = the ideas behind
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BIDIR-PIM may really go
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 too
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0far here ... if readers = haven't heard about
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BIDIR-PIM, the should
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0look up the reference.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0an IGMP proxy =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 functio= n needs to be deployed at MAGs
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in exactly the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0way as for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> an IGMP = proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 functio= n needs to be deployed at MAGs
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in exactly the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0way as is done f= or an MLD proxy for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.9
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For a dual-stack= IPv4/IPv6 access network,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the MAG proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 instances
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> For a du= al-stack IPv4/IPv6 access
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 network, the MAG proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0instances (i.e. = IPMP/MLD proxy functions)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In the following= , efficiency-related issues
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remain.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> In the f= ollowing, efficiency-related
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 issues which remain
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsolved within = the above defined base
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PMIPv6 multicast source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support are desc= ribed.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Here, we would prefer th= e shorter forms.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.11
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0upstream will le= ad traffic into the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast infrastructure
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0upstr= eam will transfer traffic into the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 infrastructure


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.12
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0configurations h= ave completed =3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 configurations have been
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 completed


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0traffic from the= mobile source continues to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be transmitted via
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 same ne= xt-hop router using the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source address
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0traff= ic from the mobile source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continues to be transmitted
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0via the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 same ne= xt-hop multicast router using
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the same source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0by aggregating p= roxies on a lower layer.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> pleas= e clarify: what layer exactly is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 proposed? PIM DR at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MAGs?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A lower layer is meant i= n the (OSI) layered
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 model: Layer 2 or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 below.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the a= ccess network for providing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast services in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unicast= routes.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0in th= e access network for providing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast services in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parallel to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unicast= routes ( see Fig. 3(b)).


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The foll= owing information is needed for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all phases of PIM.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0The f= ollowing information is needed for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all three phases of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PIM as outlined = in [RFC4601].


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.K.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0P.14
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0configured to no= t initiated (S,G) shortest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 path tress for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mobile
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> configur= ed to not initiated (S,G)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 shortest path trees for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mobile


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mobile source. = =A0This tree can be of lesser
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 routing efficiency
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 than
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> mobile s= ource. =A0This tree can be of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lower routing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 efficiency than


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 respons= e, the PIM RP will recognize
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the known source at a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (tunnel= ) interface immediately
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 responds with a register
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stop.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 respons= e, the PIM RP will recognize
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the known source at a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (tunnel= ) interface and thus (?)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 immediately respond with a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0register stop.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.k., fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0As the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RP had = joined the shortest path tree
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to receive from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0source via
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the LMA= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D>As the =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RP has = joined the shortest path tree
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to receive data from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the source via =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the LMA= ,


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Meanwhile replaced.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the LMA, it will= see an RPF change when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data arrives at a new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> the LMA,= it will see an RPF change when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data arrive at a new


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s.o.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In response to a= n exceeded threshold of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 packet transmission,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DRs of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receive= rs eventually will initiated a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source-specific
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Join for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> In respo= nse to an exceeded threshold of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 packet transmission,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DRs of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receive= rs eventually will initiate a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source-specific Join
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this (S,G) tree = will range from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the rec= eiving DR via the (stable) LMA,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the LMA-MAG tunnel
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mobile = source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this (S,G) tree = will range from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the rec= eiving DR via the (stable) LMA,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the LMA-MAG tunnel,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and the serving = MAG to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mobile = source (described from leave to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 root?)


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This tree is of = higher routing efficiency than
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0established in t= he previous phase two
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This tree is of = higher routing efficiency than
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that establ= ished in the previous phase two


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thanks, o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.15
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0via the source r= egister tunnel. =A0Tree
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mainenance eventually
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0triggered
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> via the = source register tunnel. =A0Tree
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maintenance eventually
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0triggered


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.16
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BIDIR-PI= M MAY be deployed in the access
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 network =3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BIDIR-PIM [R= FC5015] MAY be deployed in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the access network


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ref has been provided be= fore.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remain uneffecte= d by node mobility =3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remain unaffected by node
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mobility


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spanning group t= ree =3D> spanning tree for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the multicast group
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/multicast spann= ing tree


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k., thanks.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.17
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0document. =A0To = overcome these deficits, an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 optimized approach to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> AFAIU= it does mainly cover deficits
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mentioned in sect.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4, if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0also those ineff= iciencies described in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3.2.5 are tackled this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should be explai= ned


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Actually, the main conce= rns that are addressed
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in this peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0approach are from sectio= n 3.2.5, namely the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parallel proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0instances, which route v= ia an LMA.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We've added text to = make this clearer.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Following differ= ent techniques, these
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 requirements are met in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 followi= ng solutions.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> to me= it seems to be one solution only
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (peering between MLD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proxies) adapted= to several multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 protocol implementations
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for ASM and SSM<= br>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, the original text c= overed also the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple-upstream proxy,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0which moved to the appen= dix now. The text has
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 been corrected now.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but provide supe= rior performance in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 presence of source-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specifi= c signaling (IGMPv3/MLDv2).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> Would= n't a reference to RFC 4604
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ("Using Internet Group
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Management Proto= col Version 3 (IGMPv3) and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multicast Listener
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Discovery Protoc= ol Version 2 (MLDv2) for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Source-Specific
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Multicast")= make sense or be helpful here?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.k., we've added th= is.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.18
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This filter base= Must be updated, if and =3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This filter base
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MUST be updated,= if and


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thanks, fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 additio= n, local multicast packets are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 transferred
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 additio= n, multicast packets from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 locally attached sources
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are transferred<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In addition= , such locally arriving
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast packets are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0transferred


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O.k., reworded.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.19
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A06. =A0IANA Consi= derations
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TODO. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D> to me= there seem to be no IANA
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 activities arising from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposed protoco= l modifications, right?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the PMIPv6 domai= n will not actively
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 terminate group membership
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 prior
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to depa= rture.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the PMIPv6 domai= n will in general not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 actively terminate group
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0membership prior=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to depa= rture.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0o.k.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p.22
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but alternate co= nfiguriations =3D> but
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 alternate configurations

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a state decompos= ition , if needed =3D> a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state decomposition, if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0needed...


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks, fixed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hope this helps.=


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, thanks a lot for th= is detailed review!

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wishes,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-----Original Me= ssage-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From: multimob-bounces@ietf.= org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.org= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:multimob-bounces@iet= f.__org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.org= >>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[mailto:multimob-bounces@ietf.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.>___= _org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:multimob-bounces@iet= f.__org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob-bounces@ietf.org= >>] On Behalf Of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 internet-drafts@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.__org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org&g= t;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Samstag, 1= 3. Juli 2013 00:50
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To: i-d-announce@ietf.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org>>=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: multimob@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob@ietf.org> <mailto:multimob@ietf.org

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: [multim= ob] I-D Action:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-multi= mob-pmipv6-____source-04.txt



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A New Internet-D= raft is available from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on-line
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts = directories.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This draft = is a work item of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multicast Mobility Working
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Group of the IET= F.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Title =A0 =A0 =A0 =A0 =A0 : Mobile Multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sender Support in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Proxy Mobile IPv= 6 (PMIPv6) Domains
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Author(s) =A0 =A0 =A0 : Thomas C. Schmidt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Shuai Gao
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hong-Ke Zhang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Matthias Waehlisch
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Filename =A0 =A0 =A0 =A0:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-multi= mob-pmipv6-____source-04.txt

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Pages =A0 =A0 =A0 =A0 =A0 : 24
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-12

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multica= st communication can be enabled
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in Proxy Mobile
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domains
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 via the= Local Mobility Anchors by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 deploying MLD Proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functions at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mobile = Access Gateways, via a direct
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 traffic distribution
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0within an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ISP'= ;s access network, or by selective
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 route optimization
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0schemes.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This do= cument describes the support of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mobile multicast
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0senders in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Proxy M= obile IPv6 domains for all
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 three scenarios.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 optimiz= ations for synchronizing PMIPv6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with PIM, as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 well as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a peering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 functio= n for MLD Proxies defined.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mobile sources always
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remain
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 agnosti= c of multicast mobility operations.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The IETF datatra= cker status page for this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft is:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https= ://datatracker.ietf.org/____doc/draft-ietf-multimob-____pmipv= 6-source
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https= ://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-so= urce>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https= ://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-so= urce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://d= atatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source= >>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0There's also= a htmlized version available at:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://t= ools.ietf.org/html/____draft-ietf-multimob-pmipv6-____source-= 04
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://t= ools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://t= ools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://tools= .ietf.org/html/draft-ietf-multimob-pmipv6-source-04>&g= t;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A diff from the = previous version is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 available at:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-multimob-____pmipv6-source-04
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <= http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-multimob-__pm= ipv6-source-04>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <= http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-multimob-__pm= ipv6-source-04
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-sou= rce-04>>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts = are also available by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 anonymous FTP at:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-____d= rafts/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__d= rafts/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/= internet-__drafts/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-draft= s/>>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ___________________________________________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multimob mailing= list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multimob@ietf.org <mailto:multimob@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob@ietf.org <mailto:multimob@ietf.org>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/= ____listinfo/multimob
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailma= n/__listinfo/multimob>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailma= n/__listinfo/multimob
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/= listinfo/multimob>>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Prof. Dr. Thomas C. Schm= idt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B0 Hamburg University o= f Applied Sciences
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Berliner=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tor 7 =B0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B0 Dept. Informatik, In= ternet Technologies Group
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 20099 Hamburg,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Germany =B0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B0 http://www.haw-hamburg.de/inet=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fon:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +49-40-42875-8452 <tel:%= 2B49-40-42875-8452> =B0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=B0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.informatik.haw-____= hamburg.de/~schmidt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://www.informatik.haw-__= hamburg.de/~schmidt>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://www.informatik.haw-__= hamburg.de/~schmidt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://www.informatik.haw-<= /u>hamburg.de/~schmidt>> =A0 =A0Fax:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +49-40-42875-8409 <tel:%= 2B49-40-42875-8409> =B0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________= ___________________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multimob mailing list =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multimob@ietf.org <mailto:multimob@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:multimob@ietf.org <mailto:multimob@ietf.org>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/= ____listinfo/multimob
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailma= n/__listinfo/multimob>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailma= n/__listinfo/multimob
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/= listinfo/multimob>>







=A0 =A0 _________________________________________________
=A0 =A0 multimob mailing list
=A0 =A0 multimob@iet= f.org <mailto:multimob@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/multimob
=A0 =A0 <https://www.ietf.org/mailman/listinfo/multimob>=




--001a11c23c8812b66204e7dc277c-- From sarikaya2012@gmail.com Fri Oct 4 09:46:50 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C221F9D1B for ; Fri, 4 Oct 2013 09:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqtN5QYNmDby for ; Fri, 4 Oct 2013 09:46:47 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0843E21F9CC5 for ; Fri, 4 Oct 2013 09:46:35 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id x18so3538589lbi.10 for ; Fri, 04 Oct 2013 09:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=IQiA3puRvXuTShVvNiURqGg71qsJHCHGIflSSOWtwjk=; b=D3crJZTBzNr3A7o3tmob2fAlkwRLggdSDGPqBaniyLOvHeZwqP2tkPfPkirT1haNGV WaYl4KGt98EBGgOLp3w6OQa2JsTfZockGvA1SF+ODs0UDxy0Z4wdCXYS/hIeGLIqTTS9 +GhrgIQ3ROkg0lvCtwXumr/gFA1pFVc2h/wqiV2/i66Cvb8ifxb9tzFdmHCUbR19odyx 3DdpInGOwqNqak6oysVXVojtJp29IENo+bor3RJ4Q4lgeGFxIbIMVB2PVJ2RIo31KYT8 rERHVORPjvm4JSj/eHQBG0shD9iDt8/v2/8yp1+6hEq864BtdBfKyiTf5FhhsGK8ac1b Y9Kw== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr12247006lbb.14.1380905194795; Fri, 04 Oct 2013 09:46:34 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Fri, 4 Oct 2013 09:46:34 -0700 (PDT) Date: Fri, 4 Oct 2013 11:46:34 -0500 Message-ID: From: Behcet Sarikaya To: "multimob@ietf.org" Content-Type: multipart/mixed; boundary=047d7b3441d09ace3104e7ed0bca Subject: [multimob] draft-ietf-multimob-handover-optimization-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:46:50 -0000 --047d7b3441d09ace3104e7ed0bca Content-Type: multipart/alternative; boundary=047d7b3441d09ace2b04e7ed0bc8 --047d7b3441d09ace2b04e7ed0bc8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Since this document has passed the WGLC, today I submitted it to IESG for publication using the datatracker interface which somehow does not cc it to the list. I think you can view the shepherd writeup on datatracker but just in case you have to login to the datatracker I am attaching it to this mail. Regards, Behcet --047d7b3441d09ace2b04e7ed0bc8 Content-Type: text/html; charset=ISO-8859-1
Hi all,

Since this document has passed the WGLC, today I submitted it to IESG for publication using the datatracker interface which somehow does not cc it to the list.

I think you can view the shepherd writeup on datatracker but just in case you have to login to the datatracker I am attaching it to this mail.

Regards,

Behcet
--047d7b3441d09ace2b04e7ed0bc8-- --047d7b3441d09ace3104e7ed0bca Content-Type: text/plain; charset=US-ASCII; name="shepherd4hopt100413.txt" Content-Disposition: attachment; filename="shepherd4hopt100413.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hmdn9yzv0 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA0KSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWwsIEV4cGVyaW1lbnRhbCwg b3IgSGlzdG9yaWMpPyAgV2h5DQppcyB0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/ICBJcyB0 aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZCBpbiB0aGUNCnRpdGxlIHBhZ2UgaGVhZGVyPw0KDQpF eHBlcmltZW50YWwNCkl0IGlzIGV4cGVyaW1lbnRhbCBub3QgUHJvcG9zZWQgU3RhbmRhcmQgYmVj YXVzZSBXRyBpcyBub3QgYXdhcmUgb2YgYW55IHJ1bm5pbmcgDQpjb2RlIGltcGxlbWVudGF0aW9u Lg0KWWVzDQooMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9j dW1lbnQgQW5ub3VuY2VtZW50DQpXcml0ZS1VcC4gUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3Vt ZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4gUmVjZW50DQpleGFtcGxlcyBjYW4gYmUgZm91bmQg aW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkDQpkb2N1bWVudHMuIFRo ZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczoN Cg0KVGVjaG5pY2FsIFN1bW1hcnkNCg0KICBSZWxldmFudCBjb250ZW50IGNhbiBmcmVxdWVudGx5 IGJlIGZvdW5kIGluIHRoZSBhYnN0cmFjdCANCiAgYW5kL29yIGludHJvZHVjdGlvbiBvZiB0aGUg ZG9jdW1lbnQuIElmIG5vdCwgdGhpcyBtYXkgYmUgDQogIGFuIGluZGljYXRpb24gdGhhdCB0aGVy ZSBhcmUgZGVmaWNpZW5jaWVzIGluIHRoZSBhYnN0cmFjdCANCiAgb3IgaW50cm9kdWN0aW9uLg0K DQpJbiB0aGlzIGRvY3VtZW50LCBzb21lIGVuaGFuY2VtZW50cyB0byB0aGUgYmFzZSBzb2x1dGlv biBkZXNjcmliZWQgaW4gUkZDIDYyMjQgYXJlIGRlc2NyaWJlZC4gIA0KVGhlc2UgZW5oYW5jZW1l bnRzIGluY2x1ZGUgdGhlIHVzZSBvZiBhIG11bHRpY2FzdCB0cmVlIG1vYmlsaXR5IGFuY2hvciBh cyB0aGUgdG9wb2xvZ2ljYWwgDQphbmNob3IgcG9pbnQgZm9yIG11bHRpY2FzdCB0cmFmZmljLCBh cyB3ZWxsIGFzIGEgZGlyZWN0IHJvdXRpbmcgb3B0aW9uIHdoZXJlIHRoZSBNb2JpbGl0eSANCkFj Y2VzcyBHYXRld2F5IGNhbiBwcm92aWRlIGFjY2VzcyB0byBtdWx0aWNhc3QgY29udGVudCBpbiB0 aGUgbG9jYWwgbmV0d29yay4gIA0KVGhlc2UgZW5oYW5jZW1lbnRzIHByb3ZpZGUgYmVuZWZpdHMg c3VjaCBhcyByZWR1Y2luZyBtdWx0aWNhc3QgdHJhZmZpYyByZXBsaWNhdGlvbiANCmFuZCBzdXBw b3J0aW5nIGRpZmZlcmVudCBQTUlQdjYgZGVwbG95bWVudCBzY2VuYXJpb3MuDQoNCldvcmtpbmcg R3JvdXAgU3VtbWFyeQ0KDQogIFdhcyB0aGVyZSBhbnl0aGluZyBpbiBXRyBwcm9jZXNzIHRoYXQg aXMgd29ydGggbm90aW5nPyBGb3IgDQogIGV4YW1wbGUsIHdhcyB0aGVyZSBjb250cm92ZXJzeSBh Ym91dCBwYXJ0aWN1bGFyIHBvaW50cyBvciANCiAgd2VyZSB0aGVyZSBkZWNpc2lvbnMgd2hlcmUg dGhlIGNvbnNlbnN1cyB3YXMgcGFydGljdWxhcmx5IA0KICByb3VnaD8NCg0KTm8NCg0KRG9jdW1l bnQgUXVhbGl0eQ0KDQogIEFyZSB0aGVyZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhl IHByb3RvY29sPyBIYXZlIGEgDQogIHNpZ25pZmljYW50IG51bWJlciBvZiB2ZW5kb3JzIGluZGlj YXRlZCB0aGVpciBwbGFuIHRvIA0KICBpbXBsZW1lbnQgdGhlIHNwZWNpZmljYXRpb24/IEFyZSB0 aGVyZSBhbnkgcmV2aWV3ZXJzIHRoYXQgDQogIG1lcml0IHNwZWNpYWwgbWVudGlvbiBhcyBoYXZp bmcgZG9uZSBhIHRob3JvdWdoIHJldmlldywgDQogIGUuZy4sIG9uZSB0aGF0IHJlc3VsdGVkIGlu IGltcG9ydGFudCBjaGFuZ2VzIG9yIGEgDQogIGNvbmNsdXNpb24gdGhhdCB0aGUgZG9jdW1lbnQg aGFkIG5vIHN1YnN0YW50aXZlIGlzc3Vlcz8gSWYgDQogIHRoZXJlIHdhcyBhIE1JQiBEb2N0b3Is IE1lZGlhIFR5cGUgb3Igb3RoZXIgZXhwZXJ0IHJldmlldywgDQogIHdoYXQgd2FzIGl0cyBjb3Vy c2UgKGJyaWVmbHkpPyBJbiB0aGUgY2FzZSBvZiBhIE1lZGlhIFR5cGUgDQogIHJldmlldywgb24g d2hhdCBkYXRlIHdhcyB0aGUgcmVxdWVzdCBwb3N0ZWQ/DQoNClRoZXJlIGFyZSBjdXJyZW50bHkg bm8gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbCANCmRlc2NyaWJlZCBp biB0aGlzDQpkb2N1bWVudC4gDQoNClRoZSBkb2N1bWVudCBoYXMgbm8gc3VidGFudGl2ZSBpc3N1 ZXMgYXMgZXZpZGVuY2VkIGJ5IFdHTEMgY29tbWVudHMuIA0KDQpUaGVyZSB3YXMgbm8gTUlCIERv Y3RvciwgTWVkaWEgVHlwZSBvciBvdGhlciBleHBlcnQgcmV2aWV3IA0KY29uZHVjdGVkIG9uIHRo aXMgZG9jdW1lbnQuDQoNClBlcnNvbm5lbA0KDQogIFdobyBpcyB0aGUgRG9jdW1lbnQgU2hlcGhl cmQ/IFdobyBpcyB0aGUgUmVzcG9uc2libGUgQXJlYQ0KICBEaXJlY3Rvcj8NCg0KDQpEb2N1bWVu dCBTaGVwaGVyZCBpcyBCZWhjZXQgU2FyaWtheWEgUmVzcG9uc2libGUgQXJlYQ0KICBEaXJlY3Rv ciBpcyBCcmlhbiBIYWJlcm1hbg0KICANCigzKSBCcmllZmx5IGRlc2NyaWJlIHRoZSByZXZpZXcg b2YgdGhpcyBkb2N1bWVudCB0aGF0IHdhcyBwZXJmb3JtZWQgYnkNCnRoZSBEb2N1bWVudCBTaGVw aGVyZC4gIElmIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWR5DQpmb3Ig cHVibGljYXRpb24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9y d2FyZGVkIHRvDQp0aGUgSUVTRy4NCg0KVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBkb2N1 bWVudCBhbmQgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KICANCig0KSBEb2VzIHRoZSBk b2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3INCmJy ZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCBoYXZlIGJlZW4gcGVyZm9ybWVkPyAgDQoNCk5vLg0K DQooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0 aWN1bGFyIG9yIGZyb20NCmJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVy YXRpb25hbCBjb21wbGV4aXR5LCBBQUEsIEROUywNCkRIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25h bGl6YXRpb24/IElmIHNvLCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXQNCnRvb2sgcGxhY2UuDQoN Ck5vLg0KDQooNikgRGVzY3JpYmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0 IHRoZSBEb2N1bWVudCBTaGVwaGVyZA0KaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0aGUNCklFU0cgc2hvdWxkIGJlIGF3YXJl IG9mPyBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ0Kd2l0 aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IgaGFzIGNvbmNlcm5zIHdoZXRoZXIg dGhlcmUgcmVhbGx5DQppcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgZXZlbnQsIGlmIHRoZSBXRyBo YXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQNCmhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGls bCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZQ0KY29uY2VybnMg aGVyZS4NCg0KSSBoYXZlIG5vIGNvbmNlcm5zIG9uIHRoZSBkb2N1bWVudC4NCg0KKDcpIEhhcyBl YWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFINCmRp c2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lv bnMgb2YgQkNQIDc4DQphbmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBub3Qs IGV4cGxhaW4gd2h5Lg0KDQogDQoNCkVhY2ggYXV0aG9yIGNvbmZpcm1lZCBpbmRpdmlkdWFsbHkg dGhhdCBubyBJUFIgY2xhaW0gaGFzIGJlZW4gZmlsZWQgDQpvbiB0aGlzIGRvY3VtZW50IGFuZCB0 aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IGRpc2Nsb3N1cmVzLg0KDQooOCkgSGFzIGFuIElQUiBk aXNjbG9zdXJlIGJlZW4gZmlsZWQgdGhhdCByZWZlcmVuY2VzIHRoaXMgZG9jdW1lbnQ/DQpJZiBz bywgc3VtbWFyaXplIGFueSBXRyBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGluZyB0 aGUgSVBSDQpkaXNjbG9zdXJlcy4NCg0KTm8NCiANCg0KKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cg Y29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KcmVwcmVzZW50IHRoZSBz dHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdpdGggb3RoZXJzDQpiZWlu ZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQgYWdyZWUg d2l0aCBpdD8gICANCg0KVGhlcmUgaXMgYSBzdHJvbmcgY29uc2Vuc3VzIGJlaGluZCB0aGlzIHNv bHV0aW9uLg0KDQooMTApIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3 aXNlIGluZGljYXRlZCBleHRyZW1lIA0KZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJp c2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlDQplbWFpbCBtZXNzYWdlcyB0byB0 aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhDQpzZXBhcmF0 ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyBwdWJsaWNseSBhdmFpbGFibGUu KSANCg0KTm9ib2R5IGhhcyB0aHJlYXRlbmVkIHRvIGFwcGVhbCBhbmQgdGhlIGRvY3VtZW50IGhh cyB0aGUgYmFja2luZyBvZiB0aGUgV0cgYXMgYSB3aG9sZS4NCg0KKDExKSBJZGVudGlmeSBhbnkg SUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMNCmRvY3VtZW50 LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBhbmQgdGhlIEludGVybmV0 LURyYWZ0cw0KQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0 aGlzIGNoZWNrIG5lZWRzIHRvIGJlDQp0aG9yb3VnaC4NCg0KTm8gSUQgbml0IGVycm9ycy93YXJu aW5ncyBhcmUgcHJlc2VudCBvbiB0aGUgZG9jdW1lbnQgDQoNCigxMikgRGVzY3JpYmUgaG93IHRo ZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmlldw0KY3JpdGVyaWEsIHN1 Y2ggYXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0K DQpUaGUgZG9jdW1lbnQgbWVldHMgdGhlIHJldmlldyBjcml0ZXJpYS4NCg0KKDEzKSBIYXZlIGFs bCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcw0KZWl0 aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NCg0KWWVzLg0KDQooMTQpIEFyZSB0aGVyZSBu b3JtYXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCBhcmUgbm90IHJlYWR5IGZvcg0K YWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRlPyBJZiBzdWNo IG5vcm1hdGl2ZQ0KcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgcGxhbiBmb3IgdGhlaXIg Y29tcGxldGlvbj8NCg0KTm8uDQoNCigxNSkgQXJlIHRoZXJlIGRvd253YXJkIG5vcm1hdGl2ZSBy ZWZlcmVuY2VzIHJlZmVyZW5jZXMgKHNlZSBSRkMgMzk2Nyk/DQpJZiBzbywgbGlzdCB0aGVzZSBk b3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgRGlyZWN0b3IgaW4gDQp0aGUg TGFzdCBDYWxsIHByb2NlZHVyZS4gDQoNCk5vLg0KDQooMTYpIFdpbGwgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkNCmV4aXN0aW5nIFJGQ3M/IEFy ZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIsIGxpc3RlZA0KaW4g dGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBS RkNzIGFyZSBub3QNCmxpc3RlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhw bGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUNCnBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRo ZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUNCm90aGVyIFJGQ3MgaXMgZGlz Y3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsDQpleHBs YWluIHdoeSB0aGUgV0cgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5Lg0KDQpOby4NCg0KDQooMTcp IERlc2NyaWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBjb25z aWRlcmF0aW9ucw0Kc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBpdHMgY29uc2lz dGVuY3kgd2l0aCB0aGUgYm9keSBvZiB0aGUNCmRvY3VtZW50LiBDb25maXJtIHRoYXQgYWxsIHBy b3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1lbnQgbWFrZXMNCmFyZSBhc3NvY2lhdGVk IHdpdGggdGhlIGFwcHJvcHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5BIHJlZ2lzdHJpZXMuDQpD b25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVh cmx5DQppZGVudGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJp ZXMgaW5jbHVkZSBhDQpkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRl bnRzIGZvciB0aGUgcmVnaXN0cnksIHRoYXQNCmFsbG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1 dHVyZSByZWdpc3RyYXRpb25zIGFyZSBkZWZpbmVkLCBhbmQgYQ0KcmVhc29uYWJsZSBuYW1lIGZv ciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4NCg0K VGhlIGRvY3VtZW50IGRlZmluZXMgdGhyZWUgbmV3IG1vYmlsaXR5IGhlYWRlciB0eXBlcywgIG9u ZSBuZXcgbW9iaWxpdHkgDQpvcHRpb24gb25lIG5ldyBmbGFnLCB0aGUgSUFOQSByZWdpc3RyeSBp cyBpbiBNb2JpbGUgSVB2NiBwYXJhbWV0ZXJzLg0KDQooMTgpIExpc3QgYW55IG5ldyBJQU5BIHJl Z2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZQ0KYWxsb2NhdGlv bnMuIFByb3ZpZGUgYW55IHB1YmxpYyBndWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQN CnVzZWZ1bCBpbiBzZWxlY3RpbmcgdGhlIElBTkEgRXhwZXJ0cyBmb3IgdGhlc2UgbmV3IHJlZ2lz dHJpZXMuDQoNCk5vbmUuDQoNCigxOSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVkIGNo ZWNrcyBwZXJmb3JtZWQgYnkgdGhlIERvY3VtZW50DQpTaGVwaGVyZCB0byB2YWxpZGF0ZSBzZWN0 aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBhIGZvcm1hbA0KbGFuZ3VhZ2UsIHN1Y2gg YXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuDQoNCk5vIGZvcm1h bCBsYW5ndWFnZSBzZWdtZW50cyBleGlzdC4= --047d7b3441d09ace3104e7ed0bca-- From brian@innovationslab.net Thu Oct 17 07:50:38 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D3211E81B5 for ; Thu, 17 Oct 2013 07:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC3gr64E0-HD for ; Thu, 17 Oct 2013 07:50:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87C11E810F for ; Thu, 17 Oct 2013 07:50:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 63C73880D2; Thu, 17 Oct 2013 07:50:32 -0700 (PDT) Received: from Littlejohn.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D202113680E4; Thu, 17 Oct 2013 07:50:31 -0700 (PDT) Message-ID: <525FF92F.5020204@innovationslab.net> Date: Thu, 17 Oct 2013 10:50:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-multimob-handover-optimization.all@tools.ietf.org, multimob@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L7eXlU06M55rNJp9k9m44JAp95IIScXdf" Subject: [multimob] AD Evaluation: draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 14:50:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L7eXlU06M55rNJp9k9m44JAp95IIScXdf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I have completed my AD evaluation of draft-ietf-multimob-handover-optimization and found it to be quite readable. Thank you. I have a few issues that I would like to see resolved prior to requesting IETF Last Call for this document. Feel free to discuss them with me if clarifications are needed. 1. Introduction: * In the 2nd paragraph, I don't see the benefit to referencing a draft that has been expired for 3 years. I would suggest dropping the referenc= e. * In the 3rd paragraph : s/can help mitigating/can help mitigate * The last paragraph is not needed and can be deleted. 2. Several places in the beginning of the document, there are references to RFC 2710 but not RFC 3810. RFC 6224 uses both and section 4.1.1 explicitly discusses RFC 3810 (albeit indirectly as MLDv2). I would suggest referencing both, add 3810 to the Normative References, and properly reference 3810 in the appropriate places in section 4. 3. The reference to draft-ietf-multimob-pmipv6-ropt can be updated to be RFC 7028. 4. Section 1.1 * The 2nd requirement is not a protocol requirement and should be deleted. It is trying to mandate implementation/deployment behavior. * The "on" in requirement 3 can be removed. * Would it make sense to add an additional requirement that this experimental approach not impact deployments of legacy implementations of RFC 5213 and RFC 6224? 5. Section 4.1.2 : It would be clearer if the description of the message formats that are borrowed from 2710 and 3810 refer to those formats by the terms used in the RFC. For example, the Multicast Membership Context field should refer to (or be called) the Multicast Address Record (from 3810). 6. Sections 4.3.1.2 and 4.3.2.2 * Why are the sequence numbers 8-bit fields? The sequence fields in other PMIPv6 messages are 16-bit. * I would suggest adding references for the options allowed in these messages (Mobile Node Identifier, Home Network Prefix, and Active Multicast Subscription). Regards, Brian --L7eXlU06M55rNJp9k9m44JAp95IIScXdf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSX/k2AAoJEBOZRqCi7goqJA0H/1XBy06N0QaowUcC1kJgUVjt kULOhHTicQdixFvAiVOv2elKbI6XwMAYSveMerrAWMGQ/5Yjlfsj/L2P4nVKk363 kMNo+u9k44HcG9lncffXnwGZpkIer7BmPI4SqUPpj4ZZQArKeAdQNhWAYzbZH0E8 uwhEUnRvZpgnfkHOHilTSNk6v+SaA20/9oThXb9xLCyktnO9tzRFz4f9SqsVH8Zq bpd0dPyWgxvkLG7IowFLOi70Z6OaGFTtOgnjFV4rN8xKxRqMrEuLZNU+YIHQPD0O pkhRDmVKdLSEPJrJeDyd4xLJK3REHecehxaAPiyvXVJlGYiaLHRAldK1efqU1Vg= =B5UU -----END PGP SIGNATURE----- --L7eXlU06M55rNJp9k9m44JAp95IIScXdf-- From cjbc@it.uc3m.es Fri Oct 18 03:29:41 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A0E11E81B1 for ; Fri, 18 Oct 2013 03:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FPJr94zEBmK for ; Fri, 18 Oct 2013 03:29:36 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4E21F9FCF for ; Fri, 18 Oct 2013 03:29:35 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A7E85CC5BD8; Fri, 18 Oct 2013 12:29:34 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 989B8CC51F1; Fri, 18 Oct 2013 12:29:34 +0200 (CEST) Message-ID: <1382092174.4706.27.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Fri, 18 Oct 2013 12:29:34 +0200 In-Reply-To: <525FF92F.5020204@innovationslab.net> References: <525FF92F.5020204@innovationslab.net> Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-3B9+UZ+YoaNxEsvMi4JW" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20226.006 Cc: draft-ietf-multimob-handover-optimization.all@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation: draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 18 Oct 2013 10:29:41 -0000 --=-3B9+UZ+YoaNxEsvMi4JW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi Brian, Thanks for your review and comments. We have prepared a revised version (-05), attached to this e-mail but not yet posted to the I-D repository. Please see below our responses. Once you are happy with them, we can post -05 version. On Thu, 2013-10-17 at 10:50 -0400, Brian Haberman wrote: > All, > I have completed my AD evaluation of > draft-ietf-multimob-handover-optimization and found it to be quite > readable. Thank you. > > I have a few issues that I would like to see resolved prior to > requesting IETF Last Call for this document. Feel free to discuss them > with me if clarifications are needed. > > 1. Introduction: > > * In the 2nd paragraph, I don't see the benefit to referencing a draft > that has been expired for 3 years. I would suggest dropping the reference. [Authors] OK, done. > > * In the 3rd paragraph : s/can help mitigating/can help mitigate [Authors] OK, done. > > * The last paragraph is not needed and can be deleted. [Authors] OK, done. We originally added this because during the IESG evaluation of RFC7028 we got a comment requesting to add such a paragraph there. > > 2. Several places in the beginning of the document, there are references > to RFC 2710 but not RFC 3810. RFC 6224 uses both and section 4.1.1 > explicitly discusses RFC 3810 (albeit indirectly as MLDv2). I would > suggest referencing both, add 3810 to the Normative References, and > properly reference 3810 in the appropriate places in section 4. [Authors] OK, done. > > 3. The reference to draft-ietf-multimob-pmipv6-ropt can be updated to be > RFC 7028. [Authors] OK, done. > > 4. Section 1.1 > > * The 2nd requirement is not a protocol requirement and should be > deleted. It is trying to mandate implementation/deployment behavior. [Authors] OK, done. > > * The "on" in requirement 3 can be removed. [Authors] OK, done. > > * Would it make sense to add an additional requirement that this > experimental approach not impact deployments of legacy implementations > of RFC 5213 and RFC 6224? [Authors] Good point, it makes sense. We have added it. > > 5. Section 4.1.2 : It would be clearer if the description of the message > formats that are borrowed from 2710 and 3810 refer to those formats by > the terms used in the RFC. For example, the Multicast Membership > Context field should refer to (or be called) the Multicast Address > Record (from 3810). [Authors] We think we already do this: Multicast Membership Context: Multicast subscription information corresponding to a single subscribed multicast address. For MLDv2, the format of this field follows the Multicast Address Record format as defined in [RFC3810]. [Authors] But if you think that it is clearer to just use the RFC 3810 name (Multicast Address Record) for the field, we can update it. > > 6. Sections 4.3.1.2 and 4.3.2.2 > > * Why are the sequence numbers 8-bit fields? The sequence fields in > other PMIPv6 messages are 16-bit. [Authors] We believe that 8 bits are enough for this sequence space, which is enough for the purpose of the subscription query/response, as it is not expected to be used as often as PBU/PBA. Using 16-bit values would require at least extending the size of the Subscription Response message, and we thought that it was a better trade-off to use a 8-bit value. > > * I would suggest adding references for the options allowed in these > messages (Mobile Node Identifier, Home Network Prefix, and Active > Multicast Subscription). [Authors] OK, done. Thanks! Carlos > > > Regards, > Brian > --=-3B9+UZ+YoaNxEsvMi4JW Content-Disposition: attachment; filename="draft-ietf-multimob-handover-optimization-05.txt" Content-Type: text/plain; name="draft-ietf-multimob-handover-optimization-05.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit MULTIMOB Working Group LM. Contreras Internet-Draft Telefonica I+D Intended status: Experimental CJ. Bernardos Expires: April 21, 2014 I. Soto UC3M October 18, 2013 PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) draft-ietf-multimob-handover-optimization-05 Abstract This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras, et al. Expires April 21, 2014 [Page 1] Internet-Draft PMIPv6 multicast handover optimization October 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Handover optimization requirements . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Proxy Mobile IPv6 extensions . . . . . . . . . . . . . . . . . 9 4.1. Active Multicast Subscription mobility option . . . . . . 9 4.1.1. Option application rules . . . . . . . . . . . . . . . 9 4.1.2. Option format . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Backward compatibility with MLDv1 . . . . . . . . . . 10 4.2. Multicast Signaling flag on PBU/PBA message headers . . . 11 4.2.1. Flag application rules . . . . . . . . . . . . . . . . 11 4.2.1.1. Registration process . . . . . . . . . . . . . . . 11 4.2.1.2. De-registration process . . . . . . . . . . . . . 12 4.2.2. New format of conventional PBU/PBA messages . . . . . 13 4.2.2.1. Proxy Binding Update message . . . . . . . . . . . 13 4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13 4.3. Messages for active multicast subscription query . . . . . 13 4.3.1. Subscription Query message . . . . . . . . . . . . . . 14 4.3.1.1. Message application rules . . . . . . . . . . . . 14 4.3.1.2. Message format . . . . . . . . . . . . . . . . . . 14 4.3.2. Subscription Response message . . . . . . . . . . . . 15 4.3.2.1. Message application rules . . . . . . . . . . . . 15 4.3.2.2. Message format . . . . . . . . . . . . . . . . . . 15 4.4. New PBA timer in the LMA . . . . . . . . . . . . . . . . . 16 5. Handover signaling procedures . . . . . . . . . . . . . . . . 17 5.1. Handover of proactive type . . . . . . . . . . . . . . . . 17 5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Message flow description . . . . . . . . . . . . . . . 17 5.2. Handover of reactive type . . . . . . . . . . . . . . . . 19 5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Message flow description . . . . . . . . . . . . . . . 20 5.2.3. Further considerations for the reactive handover signaling . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Prevention of large delays of the binding acknowledgement for unicast traffic . . . . . . . . . . . 23 Contreras, et al. Expires April 21, 2014 [Page 2] Internet-Draft PMIPv6 multicast handover optimization October 2013 6. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Active Multicast Subscription for IPv4 . . . . . . . . . . 26 6.2. Signaling procedures for IPv4 support . . . . . . . . . . 27 6.3. Binding Cache extensions for IPv4 support . . . . . . . . 28 7. Co-existence with PMIPv6 multicast architectural evolutions . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. Performance comparison with base solution . . . . . . 32 A.1. Delay characterization of the base solution . . . . . . . 32 A.2. Delay characterization of SIAL . . . . . . . . . . . . . . 33 A.3. Performance comparison . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Contreras, et al. Expires April 21, 2014 [Page 3] Internet-Draft PMIPv6 multicast handover optimization October 2013 1. Introduction The base solution for providing continuous multicast service delivery in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]. It specifies the basic functionality needed in the Proxy Mobile IPv6 [RFC5213] entities to provide a multicast service, so continuous delivery of multicast traffic is supported by obtaining, after each handover, the on-going multicast subscription information directly from the Mobile Node (MN). When a mobile node attaches to a new Mobile Access Gateway (MAG), the mobile node is queried by the mobile access gateway through a Multicast Listener Discovery (MLD) General Query, which is sent just after any new link is set up, to get knowledge of any existing subscription, as specified in [RFC2710] and [RFC3810]. However, the base solution needs to be improved to meet some performance requirements, especially those referring to the user perceived service quality, which is seriously affected by the disruption of multicast content forwarding to the mobile node during handovers. A mobile node with an active multicast subscription, moving from one point of attachment to another within a Proxy Mobile IPv6 domain, experiences a certain delay until it resumes receiving again the multicast content that it was receiving at the previous location. Such delay causes a gap in the content reception. Two different actions can help mitigate such reception gap. One of them is to buffer at the previous mobile access gateway a copy of the multicast traffic destined to the mobile node and forward it to the new mobile access gateway, in order to deliver that traffic to the mobile node. The other possible (complementary) action is to reduce the time needed by the new mobile access gateway to get knowledge of the active multicast subscription of the mobile node (i.e., the multicast context), so the new mobile access gateway can subscribe to the multicast group(s) on behalf of the mobile node as soon as possible. While the first mechanism could potentially be accomplished by using some adaptation of [RFC5949] to multicast traffic (despite being only applicable in the case the underlying radio access technology supports layer-2 triggers, thus requiring additional support on the mobile node), there is no generic standard solution for the accelerated acquisition of the on-going multicast subscription of the mobile node. The approach followed by the base solution [RFC6224] to get knowledge of an existing multicast subscription relies on the behavior of the IGMP/MLD protocols. Both protocols send multicast membership query messages when a new link is up. The response to such a message Contreras, et al. Expires April 21, 2014 [Page 4] Internet-Draft PMIPv6 multicast handover optimization October 2013 reports any existing multicast subscriptions by the mobile node. While this is a straightforward approach, the mobile access gateway can incur in a non-negligible delay in receiving the corresponding MLD Report message. This delay is caused by the time needed for the detection of the attachment in the new link and the re-establishment of the data plane after the handover, the radio transfer delays associated with the signaling to the mobile node, and the MLD query response interval time required by this procedure (whose default value is 10 seconds as defined in [RFC2710] and [RFC3810], or between 5 and 10 seconds as considered in the best case wireless link scenario in [RFC6636]). This document extends the Proxy Mobile IPv6 signaling protocol defined in the base protocol [RFC5213] by including a new multicast information option to update Proxy Mobile IPv6 entities during the registration and de-registration processes, and new messages to trigger the transfer of multicast information. No extension is required in any of the multicast-related protocols in use (IGMP/MLD or PIM protocols). Furthermore, this specification does not substitute the standard procedures defined in [RFC6224] (e.g., the mobile access gateway continues sending an MLD Query to the entering mobile node as soon as the point-to-point link is set up), but complements them for accelerating the acquisition of the multicast content by the mobile access gateway associated to the new point-of- attachment. This document provides a signaling method internal to the network to speed up the subscription information acquisition by the mobile access gateway, in order to accelerate the multicast delivery to the mobile node after having completed a handover. By doing so, the knowledge by the mobile access gateway of the currently active multicast subscription becomes independent of the underlying radio technology dynamics and relaxes the requirement of a rapid response from the mobile node in processing IGMP/MLD control messages. Issues like radio framing, radio access contention, channel reliability, MN's capabilities (i.e., layer-2 triggering support), IGMP/MLD timers optimization for wireless environments, etc., will not impact on the observed multicast performance during handovers. The mechanisms described in this document can also be applied to the solutions defined in [RFC7028]. Furthermore, it is also independent of the role played by the mobile access gateway within the multicast network (either acting as MLD proxy or multicast router). 1.1. Handover optimization requirements A basic solution for providing support of multicast in a network- based mobility management environment has been specified in [RFC6224] Contreras, et al. Expires April 21, 2014 [Page 5] Internet-Draft PMIPv6 multicast handover optimization October 2013 without introducing changes on the original PMIPv6 specification [RFC5213]. The focus of the present document is on improving the efficiency of the base solution regarding handover performance. One of the critical aspects of the base solution is the expected delay incurred by the mobile access gateway (where the mobile node is being attached to) to be informed about the on-going multicast subscription of the entering MN, mainly due to the fact that the mechanisms provided in the base solution relay on the original MLD procedures, with long timing interactions not conceived for mobile environments. Then, the requirements to be covered by a handover optimization solution can be established in the following manner: o The solution MUST be applicable to any kind of MN (that is, not requiring any particular functionality such as for example layer-2 trigger capabilities), in such a way that any type of mobile node in a PMIPv6 domain being served with multicast traffic can benefit from the optimized solution. o The solution MUST NOT impact existing multicast protocols. o The solution MUST optimize the handover performance with respect to the performance achieved with the base solution for any kind of handover process (i.e., for proactive and reactive handovers). o The solution SHOULD minimize the number and extent of additional support (i.e., capabilities) required in the network, aiming at an easier deployment. o The solution MUST NOT impact deployments of legacy implementations of [RFC5213] and [RFC6224]. The present specification addresses all these requirements, as described in the following sections. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. This document uses the terminology referring to PMIPv6 components as defined in [RFC5213]. Additionally, the following terms are defined and used in this document. Contreras, et al. Expires April 21, 2014 [Page 6] Internet-Draft PMIPv6 multicast handover optimization October 2013 pMAG: The previous MAG or pMAG is the mobile access gateway where the MN was initially registered before a handover event. nMAG: The new MAG or nMAG is the mobile access gateway where the MN is registered at the end of the handover event. Reactive Handover: A reactive handover is a handover event in which the Local Mobility Anchor (LMA) receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG. Proactive handover: A proactive handover is a handover event where the mobile node is firstly de-registered on the local mobility anchor by the pMAG, and later on it is registered by the nMAG as consequence of changing the point of attachment. Multicast Membership Context: Along this document, multicast membership context makes reference to the information relative to the currently active multicast subscription of an MN in a handover event which is transferred between the PMIPv6 entities to support the handover optimization. 3. Overview The local mobility anchor is a key element within the PMIPv6 infrastructure, which traces the mobile node reachability along the PMIPv6 domain. Therefore the LMA is the best element to maintain the MNs' multicast subscription information up-to-date and to forward it to the rest of PMIPv6 entities (i.e., to the mobility access gateways) as needed when MNs move within the domain. The LMA has timely knowledge of the MNs' location, especially during handover events, and it is therefore able to quickly provide information to the new point of attachment (e.g., by querying the previous one). Figure 1 summarizes the main idea of the optimization. Contreras, et al. Expires April 21, 2014 [Page 7] Internet-Draft PMIPv6 multicast handover optimization October 2013 +------+ | pMAG | | +------+ | / | / | / | / | -*-*-*-*- / (MN) ( ) / | ( ) +-----+ +------+ | ( Internet )--| LMA |------| nMAG | v ( ) +-----+ +------+ ( ) -*-*-*-*- Registration <-------------- Registration Ack & Multicast Context --------------> Figure 1: High level description of the solution The local mobility anchor only obtains the detailed subscription information or multicast context during a handover event. There is no need of continuously informing the LMA about MNs' multicast state while the mobile nodes remain attached to the same mobile access gateway. Such a continuous updating procedure would significantly increase the signaling load within the PMIPv6 domain without a clear benefit. The multicast context is only critical during handovers, neither after nor before. Indicating the active subscription while the handover is ongoing guarantees that such information will be up- to-date and ready to be transferred to the new MAG where the mobile node has just attached. This solution therefore defines the Subscription Information Acquisition through the LMA (SIAL) as the procedure to inform the new MAG about the multicast subscriptions maintained by the entering MN. To be able to transfer the multicast subscription information between Proxy Mobile IPv6 entities during a handover, this document extends the PMIPv6 protocol in several ways. First of all, a new mobility option is defined to carry the multicast context of the current subscription. Furthermore, additional messages are defined to manage the interchange of the multicast information among PMIPv6 entities. Finally, some flags are defined to govern the process. Contreras, et al. Expires April 21, 2014 [Page 8] Internet-Draft PMIPv6 multicast handover optimization October 2013 4. Proxy Mobile IPv6 extensions This section outlines the extensions proposed to the PMIPv6 protocol specified in [RFC5213]. 4.1. Active Multicast Subscription mobility option 4.1.1. Option application rules A new TLV-encoded mobility option, "Active Multicast Subscription" option is defined for use with the Proxy Binding Update (PBU) and Proxy Binding Acknowledge (PBA) messages exchanged between a local mobility anchor and a mobility access gateway to transfer the multicast subscription information. This option is used for exchanging the multicast membership context. This information is carried by directly using the format defined in the original MLD specifications. There can be multiple "Active Multicast Subscription" options present in the message, one for each active subscription maintained by the mobile node when the handover is taking place (i.e., one per multicast membership context). This new option is also used for the same purposes by the new Subscription Response message defined later in this document. MLDv2 [RFC3810] is the primary objective for the definition of the option format. MLDv1 [RFC2710] is also considered for backward compatibility. 4.1.2. Option format The format of this new option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MLD Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Multicast Membership Context + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The alignment requirement of this option is 8n+1. Type: To be defined by IANA {IANA-1}, for indication of an IPv6 Active Multicast Subscription option. Contreras, et al. Expires April 21, 2014 [Page 9] Internet-Draft PMIPv6 multicast handover optimization October 2013 Length: 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. MLD type: Field used to identify the IPv6 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original MLD specifications for the Report message. For MLDv2, the MLD Type value is 143, as specified in [RFC3810]. Multicast Membership Context: Multicast subscription information corresponding to a single subscribed multicast address. For MLDv2, the format of this field follows the Multicast Address Record format as defined in [RFC3810]. 4.1.3. Backward compatibility with MLDv1 The following values are adopted when MLDv1 is used. MLD type: For MLDv1, the MLD Type value is 131, as specified in [RFC2710]. Multicast Membership Context: For MLDv1, the relevant information for multicast context is simply given, according to [RFC2710], by the multicast address of the subscribed content. In consequence, the Multicast Membership Context is defined as a 4-octet reserved field and the Multicast Address of the subscribed content as in [RFC2710], as shown next. Contreras, et al. Expires April 21, 2014 [Page 10] Internet-Draft PMIPv6 multicast handover optimization October 2013 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Multicast Address * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. Multicast Signaling flag on PBU/PBA message headers 4.2.1. Flag application rules A new flag S {IANA-2} is added in both the PBU and PBA message headers to advertise the mobile access gateway and the local mobility anchor capabilities of processing multicast- related signaling for the MN that caused the message. This flag governs the multicast-related signaling between the LMA and the MAG. As a general rule, the value of the flag in the PBA message is a copy of the value received in the PBU message. Specific rules are described in next sub-sections. 4.2.1.1. Registration process During handover, the entities involved in this process are the nMAG and the LMA. These rules also apply for the initial binding registration process. o PBU message * S=0, it indicates that the MAG sending the PBU message does not accept multicast-related signaling for the MN being attached. This can be used to discriminate PMIPv6 nodes which are not multicast enabled, for backward compatibility reasons. * S=1, it indicates that the MAG sending the PBU message accepts multicast-related signaling for the MN being attached. Depending on the type of handover (reactive or proactive) the LMA takes some actions, described later in this document. Contreras, et al. Expires April 21, 2014 [Page 11] Internet-Draft PMIPv6 multicast handover optimization October 2013 o PBA message * If S=0 in the corresponding PBU message, the value of the flag in the PBA message MUST be a copy of the value received in the PBU message (thus S=0), without any further meaning. * If S=1 in the corresponding PBU message, two sub-cases are possible: + S=1 and "Active Multicast Subscription" mobility option in the PBA message. When the MN maintains an active multicast session, if the LMA is able to provide the multicast subscription information during registration, the PBA message MUST include the "Active Multicast Subscription" mobility option. If the LMA is not able to provide such information during registration, the PBA message MUST NOT include the "Active Multicast Subscription" mobility option. This case is useful to decouple unicast and multicast signaling for an MN being registered at nMAG. A way for obtaining later active multicast-subscription information is described later in this document. + S=0 in the PBA message if the MN does not maintain an active multicast subscription (note that for backward compatibility reasons an LMA not supporting multicast related signaling would always send S=0). 4.2.1.2. De-registration process During handover, the entities involved in this process are the pMAG and the LMA. These rules apply for the binding de-registration process o PBU message * S=0, it indicates that the MN has no active multicast session (note that for backward compatibility reasons a pMAG not supporting multicast related signaling would always send S=0). * S=1, it indicates that the MN has an active multicast session, and the multicast context MUST be transported in the "Active Multicast Subscription" mobility option. o PBA message * The value of the flag in the PBA message SHOULD be 0, without any further meaning (note that for backward compatibility reasons an LMA not supporting multicast related signaling would Contreras, et al. Expires April 21, 2014 [Page 12] Internet-Draft PMIPv6 multicast handover optimization October 2013 always send S=0). 4.2.2. New format of conventional PBU/PBA messages 4.2.2.1. Proxy Binding Update message As result of the new defined flag, the PBU message format is updated as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.2.2. Proxy Binding Acknowledgement Message As result of the new defined flag, the PBA message format is updated as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|S| Rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3. Messages for active multicast subscription query A new pair of messages is defined for querying entities about the active multicast subscription of the MN when the handover is of reactive type. Contreras, et al. Expires April 21, 2014 [Page 13] Internet-Draft PMIPv6 multicast handover optimization October 2013 These messages are sent using the Mobility Header as defined in [RFC6275]. 4.3.1. Subscription Query message 4.3.1.1. Message application rules The Subscription Query message {IANA-3} is sent by the LMA towards the pMAG to query it about any existing multicast subscriptions of the MN which is being registered by the nMAG. This message is generated in case that the handover is of reactive type. Additionally, this message is sent by the nMAG towards the LMA to query it about the existing multicast subscriptions of the MN when the LMA acknowledges the PBU sent by the nMAG but the multicast context is not provided (namely, when the PBU message has set the flag S to 1, and the PBA message has set the flag S to 1 but the multicast context is missing). 4.3.1.2. Message format The Subscription Query message has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: The Sequence Number field establishes the order of the messages sent in the Subscription Query / Subscription Response dialogue between the LMA and the MAG for a certain MN. The initial Sequence Number MUST be determined by the entity which creates the message (either LMA or MAG, depending on the scenario), which is be responsible of managing this counter. Reserved: This field is unused for now. The value MUST be initialized to 0. Contreras, et al. Expires April 21, 2014 [Page 14] Internet-Draft PMIPv6 multicast handover optimization October 2013 Mobility options: This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following: * Mobile Node Identifier option [RFC4283] (mandatory). * Home Network Prefix option [RFC5213] (optional). There can be one or more instances of the Home Network Prefix option, but only one instance of the Mobile Node Identifier option. 4.3.2. Subscription Response message 4.3.2.1. Message application rules The Subscription Response message {IANA-4} is sent by the pMAG towards the LMA, or by the LMA towards the nMAG, to answer a previously received Subscription Query message, as described above. 4.3.2.2. Message format The Subscription Response message has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: The value of the Sequence Number field in the Subscriber Response message MUST be a copy of the Sequence Number received in the Subscription Query message. Multicast Information (I): The multicast Information flag I specifies if there is multicast subscription information available for the MN or not. The meaning is the following: Contreras, et al. Expires April 21, 2014 [Page 15] Internet-Draft PMIPv6 multicast handover optimization October 2013 I=0: there is no multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message. I=1: there is multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message. The multicast subscription information MUST be carried on one or more instances of the Active Multicast Subscription option in this message (one instance for each active subscription). Reserved: This field is unused for now. The value MUST be initialized to 0. Mobility options: This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are the following: * Mobile Node Identifier option [RFC4283] (mandatory). * Active Multicast Subscription option (mandatory) only when flag I=1; it MUST NOT be present in any other case. * Home Network Prefix option [RFC5213] (optional). There can be one or more instances of the Home Network Prefix option (in all cases) and the Active Multicast Subscription option (only when I=1), but only one instance of the Mobile Node Identifier option. 4.4. New PBA timer in the LMA A new timer named "PBA timer" is used in the LMA to define the maximum waiting time before the PBA message is sent to the nMAG in case the multicast subscription information relative to the MN is not yet available. The aim of this timer is to prevent potential large delays in the forwarding of unicast traffic towards the MN being registered at the nMAG. This timer allows decoupling the unicast signaling from the multicast one in the SIAL solution. This timer SHOULD be upper bounded by the constant defined in [RFC6275] INIT_BINDACK_TIMEOUT, whose default value is 1 s. This constant sets the time when the nMAG will retry the MN registration by sending again the PBU message. The "PBA timer" has to be set to a value that ensures that the nMAG does not enter the retry mode. Contreras, et al. Expires April 21, 2014 [Page 16] Internet-Draft PMIPv6 multicast handover optimization October 2013 5. Handover signaling procedures As the MN moves from one access gateway to another, the mobility- related signaling due to the handover event is carried out independently by the pMAG and the nMAG. That signaling process is not synchronized and, thus, two scenarios need to be considered depending on the order in which the LMA receives notification of the MN registration and de-registration in the nMAG and the pMAG respectively. 5.1. Handover of proactive type 5.1.1. Rationale In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG as consequence of changing the point of attachment. Only for those MNs which maintain an active multicast subscription, the pMAG includes the "Active Multicast Subscription" mobility option carrying the multicast context of the MN at that moment as part of the PBU message (with flag S set to 1). The local mobility anchor stores that information in the corresponding binding cache. If later on the MN attaches to a nMAG, this information is sent (using the same TLV option) to the nMAG as part of the PBA confirmation of the registration process (if the PBU message sent by the nMAG has the flag S set to 1). On the other hand, if no further registration happens, the multicast information is removed together with the rest of binding database for that MN. After receiving the multicast context, the nMAG can subscribe to the multicast flow(s) on behalf of the MN in case there is no other MN already receiving it at the nMAG. The multicast status can be also set in advance for the point-to-point link towards the MN. Note that the SIAL solution described here does not prevent benefiting from extended support in the mobile node/network that facilitates the proactive mode operation of the solution, e.g., based on layer-2 capabilities. 5.1.2. Message flow description Figure 2 summarizes this process. Contreras, et al. Expires April 21, 2014 [Page 17] Internet-Draft PMIPv6 multicast handover optimization October 2013 +-----+ +----+ +-----+ +----+ | MN | |pMAG| | LMA | |nMAG| +-----+ +----+ +-----+ +----+ | | | | | |==Bi-Dir Tunnel=| | | Multicast Data | | | |<---------------| | | | | | | 1) MN Detached | | | | MN Detached Event | | | | | | | |Ext'd DeReg PBU | | 2) | |--------------->| | | | | | 3) | | Accept PBU | | |(Multicast Subscription info stored) | | | | | | PBA | | 4) | |<---------------| | | | | | 5) MN Attached | | | | | | MN Attached Event | | | | | | | PBU | 6) | | |<---------------| | | | | | | | Ext'd PBA | 7) | | |--------------->| | | | | 8) | | | Accept PBA, | | | Multicast Group join | | | and P-t-P status setup | | | | | | |==Bi-Dir Tunnel=| | | | | | | | Multicast Data | |<-------------------------------------------------| | | | | | | | | Figure 2: Proactive handover The message flow is as follows: 1. A registered MN is receiving a multicast content which has been previously subscribed to by sending a standard MLD report from the mobile node to the currently serving mobile access gateway, pMAG. The pMAG keeps the multicast state of the point-to-point Contreras, et al. Expires April 21, 2014 [Page 18] Internet-Draft PMIPv6 multicast handover optimization October 2013 link with the MN. 2. The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. As a consequence, pMAG determines a detachment event corresponding to this mobile node, and updates the attachment status of this MN to the local mobility anchor by sending an extended Proxy Binding Update message, including the "Active Multicast Subscription", which contains the multicast context of the active multicast subscriptions in the moment of handover. 3. The LMA processes the PBU message. Additionally, the LMA stores in the Binding Cache the information regarding the on-going multicast subscription(s) when the detachment is initiated. This information is kept until a new registration of the MN is completed by another MAG, or until the Binding Cache expiration, according to [RFC5213]. 4. The local mobility anchor acknowledges to the pMAG the previous PBU message. 5. As a result of the handover process, the mobile node attaches to another mobility access gateway, called nMAG. 6. The nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. 7. After the analysis of the PBU message, the LMA sends an extended PBA including the "Active Multicast Subscription" option, which contains the multicast context of the active subscriptions in the moment of handover. 8. The nMAG processes the PBA message following all the standard procedures described in [RFC5213]. Additionally, with the new information relative to multicast subscription, the nMAG sets up the multicast status of the point-to-point link between the nMAG and the MN, and joins the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content due to a previous subscription ordered by another MN attached to it. From that instant, the multicast content is served to the MN. 5.2. Handover of reactive type 5.2.1. Rationale In the reactive case, the LMA receives the mobile node registration from the nMAG without having previously received the MN de- Contreras, et al. Expires April 21, 2014 [Page 19] Internet-Draft PMIPv6 multicast handover optimization October 2013 registration from the pMAG. As the nMAG is not aware of any active multicast subscription of the mobile node, the nMAG starts a conventional registration process, by sending a normal PBU message (with flag S set to 1) towards the local mobility anchor. In the reactive handover case, after MN registration at the nMAG, the local mobility anchor SHOULD generically query the pMAG for retrieving the multicast context of the on-going multicast subscription of the mobile node. However, the LMA may know in advance if the pMAG supports multicast signaling based on the value of the flag S received during the MN registration in pMAG. Specifically, in case the pMAG does not support multicast signaling (e.g., the S flag value received from pMAG at the time of registering the mobile node was 0), the LMA MAY decide not to query pMAG even in the case of receiving an nMAG indication of supporting multicast signaling. Once the multicast subscription information is retrieved from the pMAG, the LMA encapsulates it in the PBA message by using the TLV option "Active Multicast Subscription", and forwards the PBA message to the nMAG. Then, the nMAG can subscribe the multicast flow on behalf of the MN, if there is no other mobile node receiving it already at the nMAG. The multicast status can be also set in advance for the point- to-point link towards the mobile node. 5.2.2. Message flow description Figure 3 summarizes this process. Contreras, et al. Expires April 21, 2014 [Page 20] Internet-Draft PMIPv6 multicast handover optimization October 2013 +-----+ +----+ +-----+ +----+ | MN | |pMAG| | LMA | |nMAG| +-----+ +----+ +-----+ +----+ | | | | | | | MN Attached Event | | | | | | | PBU | 1) | | |<---------------| | | | | | | Subscr Query | | 2) | |<---------------| | | | | | | | Subscr Resp | | 3) | |--------------->| | | | | | | | (Multicast Subscription | | | info forwarding) | | | | | | | | Ext'd PBA | 4) | | |--------------->| | | | | 5) | | | Accept PBA, | | | Multicast Group join | | | and P-t-P status setup | | | | | | |==Bi-Dir Tunnel=| | | | | | | | (S,G) Data | |<-------------------------------------------------| | | | | | | | | Figure 3: Reactive handover We next take as starting point the situation where an MN is attached to the pMAG, being multicast-enabled and maintaining an active multicast subscription at this moment. The sequence of messages for the handover of the mobile node is the following (as depicted in Figure 3): 1. At certain time, the MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. Then, the nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process. Contreras, et al. Expires April 21, 2014 [Page 21] Internet-Draft PMIPv6 multicast handover optimization October 2013 2. Prior to acknowledging the received PBU message, the LMA queries the pMAG about if there is any active multicast subscription for the MN, by sending a Subscription Query message. 3. The pMAG answers the LMA with a Subscription Response message including the multicast context of the existing subscriptions. 4. After processing the pMAG answer, the LMA acknowledges (with flag S set to 1) the PBU message, including the multicast subscription information within the "Active Multicast Subscription" option. The nMAG then processes the extended PBA message. 5. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up between the nMAG and the local mobility anchor if it has not been established before by another MN connection. At this moment, the multicast content can be served to the MN. The unicast traffic for the mobile node can be forwarded as well. 5.2.3. Further considerations for the reactive handover signaling A handover event is managed independently by the pMAG and nMAG. It is not a synchronized process. In a reactive handover, the LMA receives a registration PBU from nMAG before a de-registration PBU is received from pMAG. In the message flows detailed above, it could be the case that the LMA receives a de-registration PBU from pMAG just after sending the Subscription Query message, but before receiving the Subscription Response message. That de-registration PBU message from pMAG carries the multicast subscription information required to assist the MN in the handover, so such valuable information SHOULD be kept by the LMA. Furthermore, it is possible that once the Subscription Query message arrives to pMAG, the pMAG could have already removed the multicast related information for the MN. In order to avoid losing the multicast subscription information sent in the de-registration PBU message, the local mobility anchor SHOULD store it, and SHOULD include it in the PBA message towards the nMAG in case the Subscription Response message from the pMAG does not contain multicast subscription information for the mobile node. Contreras, et al. Expires April 21, 2014 [Page 22] Internet-Draft PMIPv6 multicast handover optimization October 2013 5.3. Prevention of large delays of the binding acknowledgement for unicast traffic According to the message sequences described for the reactive handover case, in case the LMA has to request the multicast subscription information from the pMAG, the binding request sent by the nMAG is maintained on-hold until the local mobility anchor receives, processes and includes the multicast subscription information into the extended PBA message. As consequence, the unicast traffic may then suffer an extra delay motivated by the multicast-related signaling. During that time, the unicast traffic with destination the MN being registered by the nMAG MAY be buffered by the local mobility anchor. In order to avoid any potential large delay in the forwarding of unicast traffic arriving at the LMA towards the MN, a mechanism SHOULD be implemented to decouple multicast from unicast traffic reception by the MN. Figure 4 shows this mechanism. Contreras, et al. Expires April 21, 2014 [Page 23] Internet-Draft PMIPv6 multicast handover optimization October 2013 +-----+ +----+ +-----+ +----+ | MN | |pMAG| | LMA | |nMAG| +-----+ +----+ +-----+ +----+ 1) | |==Bi-Dir Tunnel=| | | unicast data | | | |<-v-v-v-v-v-v-v-| | | | | | | | Multicast Data | | | |<---------------| | | | | | MN Attached Event | | | PBU | 2) | | |<---------------| | | Subscr Query | | 3) | |<---------------| | | | | | 4) | | | | | /// | | | /// | 5) | | | | | | | | | | Ext'd PBA | | | |--------------->| | | | | | | | Accept PBA | | | | | | |==Bi-Dir Tunnel=| | | | | | | | Unicast Data | |<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-| | | | | | | | Subscr Query | 6) | | |<---------------| | | Subscr Resp | | 7) | |--------------->| | | | | | | | (Multicast Subscription | | | info forwarding) | | | | | | | | Subscr Resp | 8) | | |--------------->| | | | | | | | Multicast Group join | | | and P-t-P status setup | | Multicast Data | | |<-------------------------------------------------| | | | | Figure 4: Decoupling of unicast and multicast signaling Contreras, et al. Expires April 21, 2014 [Page 24] Internet-Draft PMIPv6 multicast handover optimization October 2013 The sequence of messages is the following: 1. An MN is attached to the pMAG. The MN is a multicast-enabled node, and it is receiving both unicast and multicast traffic simultaneously. 2. Some time later, The MN initiates a handover process (e.g., because of better radio conditions) over a radio access controlled by a new mobile access gateway. Then, the nMAG triggers a registration process by sending a PBU message (with flag S set to 1) to the local mobility anchor. As it is a reactive case, the pMAG is not aware of the detachment process. 3. Prior to acknowledging the received PBU message, the LMA decides to query the pMAG about if there is any active multicast subscription for the mobile node, by sending a Subscription Query message. 4. Immediately after sending the Subscription Query message, the LMA starts the timer "PBA timer", which determines the maximum waiting time before the PBA is sent to avoid any potential large delay in the forwarding of unicast traffic towards the MN. 5. In case the "PBA timer" expires, the LMA acknowledges the PBU message, by sending the PBA message with flag S=1, without the multicast context information. The nMAG then processes the extended PBA message. Such acknowledgement allows the mobile node to receive the unicast traffic from that time on. The bidirectional tunnel is also set up between the nMAG and the LMA if it has not been established before. 6. In parallel, the nMAG sends a Subscription Query message to the LMA requesting the multicast-subscription details yet unknown for the mobile node. 7. The pMAG answers the Subscription Query message originally sent by the local mobility anchor, including the multicast context. 8. After processing the pMAG answer, the LMA sends a Subscription Response message to the nMAG, including the multicast subscription information within the "Active Multicast Subscription" option. The nMAG processes the PBA message, and it proceeds to set up the multicast status of the point-to-point link between the nMAG and the mobile node, and to join the content identified by (S,G) on behalf of the MN in case the nMAG is not receiving already such content. The bidirectional tunnel is also set up between the nMAG and the LMA if it has not been established before. At this moment, the multicast content can Contreras, et al. Expires April 21, 2014 [Page 25] Internet-Draft PMIPv6 multicast handover optimization October 2013 also be served to the mobile node. 6. IPv4 support IPv4-based mobile nodes (being either IPv4/IPv6 dual-stack, or IPv4- only enabled) can be supported in a PMIPv6 domain according to [RFC5844]. When referring to multicast membership protocols and procedures, this means that IGMP functionality has to be also supported between the PMIPv6 entities, as documented in [RFC6224], to allow the mobile access gateway requesting multicast contents to the mobility anchor on behalf of the mobile nodes attached to it. 6.1. Active Multicast Subscription for IPv4 The Active Multicast Subscription option defined in Section 4.1, which transports the multicast membership context of the mobile node during handover, should be compatible with IGMP-based formats. Specifically, the option format is defined for IPv4-based MNs as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IGMP Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Multicast Membership Context + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IGMPv3 is the primary objective for the definition of the option format. IGMPv1 and IGMPv2 are also considered for backward compatibility. The alignment requirement of this option is 4n+1. Type: To be defined by IANA {IANA-5}, for indication of an IPv4 Active Multicast Subscription option. Length: 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. IGMP type: Contreras, et al. Expires April 21, 2014 [Page 26] Internet-Draft PMIPv6 multicast handover optimization October 2013 Field used to identify the IPv4 multicast membership protocol in use, and the corresponding format of the next Multicast Membership Context information field. This field maps the type codification used in the original IGMP specifications for the Report message. 0x12: Use of IGMPv1 multicast membership protocol. 0x16: Use of IGMPv2 multicast membership protocol. 0x22: Use of IGMPv3 multicast membership protocol. Multicast Membership Context: Multicast subscription information corresponding to a single subscribed multicast address. Depending on the IGMP version being used by the mobile node, the format of the Multicast Context could follow the following formats: * For IGMPv1, the Group Address format as defined in [RFC1112]. * For IGMPv2, the Group Address format as defined in [RFC2236]. * For IGMPv3, the Group Record format as defined in [RFC3376]. 6.2. Signaling procedures for IPv4 support Generic signaling procedures for the support of IPv4 in PMIPv6 domains have been already specified in [RFC5844]. In order to prevent errors while signaling the on-going multicast subscription for a mobile node during the handover process, the following extensions have to be considered in SIAL. o If the registration / de-registration process in a handover is for an IPv6-only MN, and the type of the received Active Multicast Subscription option indicates IPv4, then the multicast membership context received MUST be silently discarded. o If the registration / de-registration process in a handover is for an IPv4-only MN, and the type of the received Active Multicast Subscription option indicates IPv6, then the multicast membership context received MUST be silently discarded. o If the registration / de-registration process in a handover is for a dual stack MN, the received Active Multicast Subscription option (or options) MUST be accepted independently of the type indication. Contreras, et al. Expires April 21, 2014 [Page 27] Internet-Draft PMIPv6 multicast handover optimization October 2013 6.3. Binding Cache extensions for IPv4 support Additionally, since the multicast membership information is temporally stored in the mobility anchor under some circumstances (e.g., proactive handover), the Binding Cache entry for an IPv4-based multicast-enabled MN should be extended for storing the IGMP-based context formats mentioned above, including the IGMP version indicator. 7. Co-existence with PMIPv6 multicast architectural evolutions Throughout this document, the base solution for multicast support in Proxy Mobile IPv6, described in [RFC6224], has been implicitly considered, i.e., both unicast and multicast traffic addressing a mobile node is delivered via the standard PMIPv6 bi-directional tunnel between LMA and MAG. While here all multicast traffic is assumed to be delivered via the local mobility anchor, the SIAL approach described in this document can be also applied to other solutions in which the multicast content is served from other entities in the PMIPv6 domain, as described in [RFC7028] to solve the tunnel convergence problem. In this case, the transfer of the multicast context would also pass through the local mobility anchor, as described here. However, the nMAG subscribes to the multicast content through the node in charge of distributing multicast according to the adopted solution for multicast distribution in the PMIPv6 domain. 8. Security Considerations This proposal does not pose any additional security threats to those already identified in [RFC5213]. All the security considerations in [RFC5213] are directly applicable to this protocol. The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement (extended with the new options defined in this document), the Subscription Query Message, and the Subscription Response Message exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The mobile access gateway and the local mobility anchor MUST implement the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document. In the following, we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect the new signaling introduced by this specification (Subscription Query Contreras, et al. Expires April 21, 2014 [Page 28] Internet-Draft PMIPv6 multicast handover optimization October 2013 Message and Subscription Response Message). We use the same format used by [RFC4877]. The SPD and SAD entries are only example configurations. A particular mobile access gateway implementation and a local mobility anchor home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the signaling messages. For the examples described in this document, a mobile access gateway with address "mag_address_1", and a local mobility anchor with address "lma_address_1" are assumed. mobile access gateway SPD-S: - IF local_address = mag_address_1 & remote_address = lma_address_1 & proto = MH & (remote_mh_type = Subscription Query | local_mh_type = Subscription Response | remote_mh_type = Multicast Activity Indication Ack.| local_mh_type = Multicast Activity Indication) Then use SA1 (OUT) and SA2 (IN) mobile access gateway SAD: - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): local_address = mag_address_1 & remote_address = lma_address_1 & proto = MH - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): local_address = lma_address_1 & remote_address = mag_address_1 & proto = MH local mobility anchor SPD-S: - IF local_address = lma_address_1 & remote_address =mag_address_1 & proto = MH & (remote_mh_type = Subscription Response | local_mh_type = Subscription Query | remote_mh_type = Multicast Activity Indication | local_mh_type = Multicast Activity Indication Ack.) Then use SA2 (OUT) and SA1 (IN) local mobility anchor SAD: - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): local_address = lma_address_1 & remote_address = mag_address_1 & proto = MH - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): local_address = mag_address_1 & remote_address = lma_address_1 & proto = MH Contreras, et al. Expires April 21, 2014 [Page 29] Internet-Draft PMIPv6 multicast handover optimization October 2013 9. IANA Considerations This document defines the new following elements which values to be allocated by IANA: o Mobility Header types: the Subscription Query {IANA-3} and Subscription Response {IANA-4} mobility header types. The Type value for these Headers has been assigned from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry defined in http://www.iana.org/assignments/mobility-parameters. o Mobility options: the Active Multicast Subscription mobility option for both IPv4 {IANA-5} and IPv6 {IANA-1} modes of operation. The Type value for these Mobility options has been assigned from the "Mobility Options" registry defined in http://www.iana.org/assignments/mobility-parameters. o Flags: this document reserves a new multicast Signaling flag (S) {IANA-2}. This Flag has been reserved at the "Binding Update Flags" and "Binding Acknowledgment Flags" registries defined in http://www.iana.org/assignments/mobility-parameters. 10. Contributors Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von-Hugo@telekom.de) extensively contributed to this document. 11. Acknowledgments The authors would like to thank (in alphabetical order) Hitoshi Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt and Stig Venaas for their valuable comments and discussions on the Multimob mailing list. The authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet Sarikaya and Stig Venaas for their reviews of this document. The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project), being also partially supported by the Ministry of Science and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 13992-C02-01). The research of Ignacio Soto has also received funding from the Spanish MICINN through the I-MOVING project (TEC2010-18907). Contreras, et al. Expires April 21, 2014 [Page 30] Internet-Draft PMIPv6 multicast handover optimization October 2013 12. References 12.1. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 12.2. Informative References [Papagiannaki] Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and C. Diot, "Measurement and Analysis of Single-Hop Delay on an IP Backbone Network", IEEE Journal on Selected Areas in Communications, vol.21, no.6 , August 2003. Contreras, et al. Expires April 21, 2014 [Page 31] Internet-Draft PMIPv6 multicast handover optimization October 2013 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011. [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012. [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013. [Verizon] "LTE: The Future of Mobile Broadband Technology", Verizon White Paper (http://opennetwork.verizonwireless.com/pdfs/ VZW_LTE_White_Paper_12-10.pdf) , 2010. [Y.1541] "Network performance objectives for IP-based services", ITU-T Recommendation Y.1541 , December 2011. Appendix A. Performance comparison with base solution This informative annex briefly analyzes and compares the performance improvement provided by the fast handover extensions specified in this document with the base multicast solution defined in [RFC6224]. The main aim is to determine the potential delay reduction in the acquisition of the multicast subscription information by the nMAG during the MN handover. To do that, the analysis focuses on the delay additional to the unicast handover due to the multicast operation in both cases. Different delay components have to be taken into account for this comparison. Since the interaction between the actors during the handover process (MN, pMAG, nMAG, LMA) is different for each of the solutions, then different sources of delay can be expected for each of them. A.1. Delay characterization of the base solution The base solution relies on the standard MLD procedures to obtain the multicast subscription information directly from the MN. Once the nMAG completes the configuration of point-to-point link to the attaching MN (the configuration of this link as downstream interface Contreras, et al. Expires April 21, 2014 [Page 32] Internet-Draft PMIPv6 multicast handover optimization October 2013 of an MLD proxy instance can run in parallel), it immediately sends an MLD General Query towards the MN for getting knowledge of any active multicast subscription by the MN. When the MN receives the MLD Query, the MN provides information about the active memberships it maintains in the form of an MLD Report message. After successful transmission of this information via the wireless point of attachment to nMAG the corresponding MLD proxy instance at the nMAG sets up the multicast status of the downstream interface. According to this process, the delay is originated on the MAG-MN communication. The delay components to be considered for the base solution are the following: o D_bh, which is the unidirectional (one way) delay encountered in the transmission path between the nMAG and the wireless point of attachment. o D_radio, which is the unidirectional delay due to the transfer of MLD control messages over the radio channel (user plane) between the wireless point of attachment and the MN, for the MLD Query and Report messages. o D_mld, which is the delay incurred by the MN to answer the MLD Query. The total observed delay can be then formulated as: D_base = 2 x (D_bh + D_radio) + D_mld A.2. Delay characterization of SIAL As described in this document, it is possible to distinguish two scenarios depending on the order in which the LMA receives the notifications of the MN registration and de-registration in the nMAG and the pMAG respectively. In the proactive case, the MN is firstly de-registered by the pMAG, and later on it is registered by the nMAG. As specified in this document, the LMA stores the multicast subscription information, which is be provided to the nMAG during the MN registration process. Since the registration process necessarily happens before the MLD Query and Report process described in the base solution, the proactive case is inherently faster than the base solution. In fact, since the multicast subscription information is acquired properly during the registration process, the delay incurred is null. In the reactive case, the LMA receives the MN registration from the nMAG without having previously received the MN de-registration from Contreras, et al. Expires April 21, 2014 [Page 33] Internet-Draft PMIPv6 multicast handover optimization October 2013 the pMAG. In case the MN maintains an active subscription, the LMA queries the pMAG to retrieve the multicast subscription information, which is forwarded to the nMAG. According to this process, the delay is originated on the MAG-LMA communication. The delay components to be considered for the base solution are the following: o D_net, which is the unidirectional delay found in the network path between the LMA and the MAG. The total observed delay can be then formulated as: D_sial = 2 x D_net A.3. Performance comparison The performance of the base solution is highly dependent on the radio technology used by the MN to attach to the PMIPv6-Domain. Different radio technologies have distinct properties in terms of radio framing, radio access contention or collision avoidance, channel reliability, etc. New radio access technologies, such as the one specified in new Long Term Evolution (LTE) standards intend to reduce the latency in order to provide high speed communications. Even though, typical one-way latencies in the LTE radio access will stay around 15 ms [Verizon]. The backhaul delay characterization becomes problematic. In a real network there are several solutions for the backhaul connection in terms of network topology (ring, star, point-to-point, etc) and technology (optical fiber, microwave transmission, xDSL-based accesses, etc), all of them having distinct properties in terms of performance, reliability and delay. These solutions commonly coexist in a real mobile network, in such a way that an MN changing the point of attachment can pass smoothly from one solution to another. A value of D_bh=5 ms can be established as typical value for the backhaul latency in modern networks. Finally, the MLD induced delay is intrinsic to the MLD protocol specification. A host receiving an MLD Query message waits a random time in the range (0, Maximum Response Delay) to send the MLD Report message. The default value of the Maximum Response Delay (configurable through the Query Response Interval in MLD) is 10 s in [RFC2710], or 5 s in the best case described in [RFC6636]. Then, in average, it can be expected a potential delay of 5 or 2,5 s, respectively. Contreras, et al. Expires April 21, 2014 [Page 34] Internet-Draft PMIPv6 multicast handover optimization October 2013 As we have seen, D_base is, on average, greater than 2,5 sec with the best case of the values of Query Response Interval in MLD that are recommended in [RFC6636]. That means that the handover delay of the base solution is on the order of seconds while in the solution presented in this specification it is on the order of milliseconds (as it is shown below). To improve the performance of the base solution we could further reduce the value of Query Response Interval but the implications of doing so would need to be carefully analyzed. Even if we assume that Query Response Interval is 0 sec, D_base would be of around 2 x (5 ms + 15 ms) = 40 ms for last generation systems. Note that this calculation does not take into account the necessary time to re-establish the data plane after the handover to make possible the MLD Query reception. The expected delay will get much worse for older generation systems (e.g., 3G-based radio systems can suffer radio delays in the order of hundreds of ms). For the SIAL case, the delay in the MAG-LMA communication will be derived from the network diameter (i.e., the number of hops found between the MAG and the LMA in the PMIPv6-Domain). This is largely influenced by the internal network planning. An administrative domain can typically have in the order of 5 hops from access to the interconnection gateway providing connectivity to other networks. Even if the LMA plays a central role topologically in the PMIPv6 domain, such number of hops seems reasonable in a common nation-wide network. Each hop in the path between MAG and LMA will add a certain delay, which can be estimated to be around 1 ms in the best case [Papagiannaki] and 3 ms in the worst case [Y.1541]. With this in mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can be expected in the worst case. Then, as conclusion, in a typical deployment, it can be stated that SIAL proposal, even for the worst-case consideration, will perform better than the best case situation for the base solution, which consists of the last generation radio technology, LTE. For any other radio technology the base solution will show even larger deviations from the delay achievable with the SIAL solution. Contreras, et al. Expires April 21, 2014 [Page 35] Internet-Draft PMIPv6 multicast handover optimization October 2013 Authors' Addresses Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: lmcm@tid.es Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Email: isoto@it.uc3m.es Contreras, et al. Expires April 21, 2014 [Page 36] --=-3B9+UZ+YoaNxEsvMi4JW-- From brian@innovationslab.net Fri Oct 18 10:43:50 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E077C11E8109 for ; Fri, 18 Oct 2013 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tALJ80OgEp0c for ; Fri, 18 Oct 2013 10:43:44 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7311E80F9 for ; Fri, 18 Oct 2013 10:43:44 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 99CDD880A7; Fri, 18 Oct 2013 10:43:41 -0700 (PDT) Received: from 102525207.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2A1E6130003; Fri, 18 Oct 2013 10:43:41 -0700 (PDT) Message-ID: <5261733B.60909@innovationslab.net> Date: Fri, 18 Oct 2013 13:43:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= References: <525FF92F.5020204@innovationslab.net> <1382092174.4706.27.camel@acorde.it.uc3m.es> In-Reply-To: <1382092174.4706.27.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IJA9L7MOdfnAtoVoO98O16RwFEwFVrjKC" Cc: draft-ietf-multimob-handover-optimization.all@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation: draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:43:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IJA9L7MOdfnAtoVoO98O16RwFEwFVrjKC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, I have pared down the points to just those needing a response... On 10/18/13 6:29 AM, Carlos Jes=FAs Bernardos Cano wrote: >=20 >> >> * The last paragraph is not needed and can be deleted. >=20 > [Authors] OK, done. We originally added this because during the IESG > evaluation of RFC7028 we got a comment requesting to add such a > paragraph there. >=20 This time around, I will do my best to stop such silliness. :) >=20 >> >> 5. Section 4.1.2 : It would be clearer if the description of the messa= ge >> formats that are borrowed from 2710 and 3810 refer to those formats by= >> the terms used in the RFC. For example, the Multicast Membership >> Context field should refer to (or be called) the Multicast Address >> Record (from 3810). >=20 > [Authors] We think we already do this: >=20 > Multicast Membership Context: >=20 > Multicast subscription information corresponding to a single > subscribed multicast address. For MLDv2, the format of this fiel= d > follows the Multicast Address Record format as defined in > [RFC3810]. >=20 > [Authors] But if you think that it is clearer to just use the RFC 3810 > name (Multicast Address Record) for the field, we can update it. >=20 You are right. The existing text is sufficient. >> >> 6. Sections 4.3.1.2 and 4.3.2.2 >> >> * Why are the sequence numbers 8-bit fields? The sequence fields in >> other PMIPv6 messages are 16-bit. >=20 > [Authors] We believe that 8 bits are enough for this sequence space, > which is enough for the purpose of the subscription query/response, as > it is not expected to be used as often as PBU/PBA. Using 16-bit values > would require at least extending the size of the Subscription Response > message, and we thought that it was a better trade-off to use a 8-bit > value. >=20 Ok. This is nothing to worry about now. Don't be surprised if someone during IETF Last Call or IESG Review asks for text in the document explaining why the sequence number spaces have different sized. Go ahead and submit the new version and I will move it along in the publication process. Regards, Brian --IJA9L7MOdfnAtoVoO98O16RwFEwFVrjKC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSYXNBAAoJEBOZRqCi7goqKigH/iTQrXG38JY0NbNjS20jjcNt zyMTBYA27YipOao9PoGL+vRfW2dkw5HmgB/wNebwL7hh4u2zJGU2WYvVtVphLu/9 A+O054KHrn/RPSkANQcwfQcM/rkQnVvrtgWU7D/zohrXK1PiRjC6xbDIKHLqYPPn /cGIW8L3sl+2MZmHvk3PfEqe3HohCwXBbIOVClzwwKX+8+tEIHA3vNG3C+oxPF5O 3I0XNLMgMiuTQuitT7ZoefFbUvb3e2Vas2PPaeTpGJppnxjAHJo0rSt095e9Unqx mj/lJnbQxGgZstFMbIezrnBbH3MX7pNnp4VF4cmbwQsYC4c34qLuK9bsJwwnaGo= =NRwD -----END PGP SIGNATURE----- --IJA9L7MOdfnAtoVoO98O16RwFEwFVrjKC-- From internet-drafts@ietf.org Fri Oct 18 11:36:37 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B0811E826F; Fri, 18 Oct 2013 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DGt7sG06Hwo; Fri, 18 Oct 2013 11:36:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CB811E80DE; Fri, 18 Oct 2013 11:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018183622.4069.16268.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 11:36:22 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-handover-optimization-05.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:36:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : PMIPv6 multicast handover optimization by the Subscripti= on Information Acquisition through the LMA (SIAL) Author(s) : Luis M. Contreras Carlos J. Bernardos Ignacio Soto Filename : draft-ietf-multimob-handover-optimization-05.txt Pages : 36 Date : 2013-10-18 Abstract: This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-handover-optimizatio= n-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Fri Oct 18 11:37:23 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287F011E825D for ; Fri, 18 Oct 2013 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rea5aeSs4F+d for ; Fri, 18 Oct 2013 11:37:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 079F811E831E for ; Fri, 18 Oct 2013 11:37:07 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38908CD6562; Fri, 18 Oct 2013 20:37:07 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 05947CD6511; Fri, 18 Oct 2013 20:37:06 +0200 (CEST) Message-ID: <1382121426.3971.3.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Fri, 18 Oct 2013 20:37:06 +0200 In-Reply-To: <5261733B.60909@innovationslab.net> References: <525FF92F.5020204@innovationslab.net> <1382092174.4706.27.camel@acorde.it.uc3m.es> <5261733B.60909@innovationslab.net> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20228.001 Cc: draft-ietf-multimob-handover-optimization.all@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation: draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 18 Oct 2013 18:37:23 -0000 Hi Brian, Thanks for the quick response. We have just submitted the -05 revision. Thanks, Carlos On Fri, 2013-10-18 at 13:43 -0400, Brian Haberman wrote: > Hi Carlos, > I have pared down the points to just those needing a response... > > On 10/18/13 6:29 AM, Carlos Jesús Bernardos Cano wrote: > > > >> > >> * The last paragraph is not needed and can be deleted. > > > > [Authors] OK, done. We originally added this because during the IESG > > evaluation of RFC7028 we got a comment requesting to add such a > > paragraph there. > > > > This time around, I will do my best to stop such silliness. :) > > > > >> > >> 5. Section 4.1.2 : It would be clearer if the description of the message > >> formats that are borrowed from 2710 and 3810 refer to those formats by > >> the terms used in the RFC. For example, the Multicast Membership > >> Context field should refer to (or be called) the Multicast Address > >> Record (from 3810). > > > > [Authors] We think we already do this: > > > > Multicast Membership Context: > > > > Multicast subscription information corresponding to a single > > subscribed multicast address. For MLDv2, the format of this field > > follows the Multicast Address Record format as defined in > > [RFC3810]. > > > > [Authors] But if you think that it is clearer to just use the RFC 3810 > > name (Multicast Address Record) for the field, we can update it. > > > > You are right. The existing text is sufficient. > > >> > >> 6. Sections 4.3.1.2 and 4.3.2.2 > >> > >> * Why are the sequence numbers 8-bit fields? The sequence fields in > >> other PMIPv6 messages are 16-bit. > > > > [Authors] We believe that 8 bits are enough for this sequence space, > > which is enough for the purpose of the subscription query/response, as > > it is not expected to be used as often as PBU/PBA. Using 16-bit values > > would require at least extending the size of the Subscription Response > > message, and we thought that it was a better trade-off to use a 8-bit > > value. > > > > Ok. This is nothing to worry about now. Don't be surprised if someone > during IETF Last Call or IESG Review asks for text in the document > explaining why the sequence number spaces have different sized. > > Go ahead and submit the new version and I will move it along in the > publication process. > > Regards, > Brian > From iesg-secretary@ietf.org Fri Oct 18 12:13:43 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3321F9FA4; Fri, 18 Oct 2013 12:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAeVJFj4C045; Fri, 18 Oct 2013 12:13:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9F11E81B8; Fri, 18 Oct 2013 12:13:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131018191340.4087.8046.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 12:13:40 -0700 Cc: multimob@ietf.org Subject: [multimob] Last Call: (PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)) to Experimental RFC X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:13:43 -0000 The IESG has received a request from the Multicast Mobility WG (multimob) to consider the following document: - 'PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Sat Oct 19 09:32:20 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD011E8211; Sat, 19 Oct 2013 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbS588Iw2xEr; Sat, 19 Oct 2013 09:32:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1208811E8212; Sat, 19 Oct 2013 09:32:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019163218.9669.95115.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 09:32:18 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 16:32:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PM= IPv6) Domains Author(s) : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-06.txt Pages : 26 Date : 2013-10-19 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=9971184ee=schmidt@informatik.haw-hamburg.de Sat Oct 19 10:14:42 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF7211E8228 for ; Sat, 19 Oct 2013 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 663bvXCMBH84 for ; Sat, 19 Oct 2013 10:14:37 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 626DA11E8214 for ; Sat, 19 Oct 2013 10:14:36 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 19 Oct 2013 19:14:35 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 4D9A6104AEB1 for ; Sat, 19 Oct 2013 19:14:35 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23031-04 for ; Sat, 19 Oct 2013 19:14:34 +0200 (CEST) Received: from [192.168.178.33] (g231104153.adsl.alicedsl.de [92.231.104.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id B9A041068726 for ; Sat, 19 Oct 2013 19:14:34 +0200 (CEST) Message-ID: <5262BDF5.8010507@informatik.haw-hamburg.de> Date: Sat, 19 Oct 2013 19:14:29 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "multimob@ietf.org" References: <20131019163218.9669.48052.idtracker@ietfa.amsl.com> In-Reply-To: <20131019163218.9669.48052.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131019163218.9669.48052.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-source-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 17:14:42 -0000 Hi folks, we have eliminated the sub-clause objected by Cong ... the draft should be fully ready for WGLC, now. Thomas A new version of I-D, draft-ietf-multimob-pmipv6-source-06.txt has been successfully submitted by Thomas C. Schmidt and posted to the IETF repository. Filename: draft-ietf-multimob-pmipv6-source Revision: 06 Title: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Creation date: 2013-10-19 Group: multimob Number of pages: 26 URL: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-source-06.txt Status: http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source Htmlized: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-06 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From sarikaya2012@gmail.com Mon Oct 21 08:18:15 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4922611E855F for ; Mon, 21 Oct 2013 08:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUd8YXvgwR44 for ; Mon, 21 Oct 2013 08:18:14 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id CE68F11E81C5 for ; Mon, 21 Oct 2013 08:17:58 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so854636lbh.35 for ; Mon, 21 Oct 2013 08:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j96G/1hUfsXUKD28/LJdV4ugHIsWCx69hZA0roAHS/c=; b=W0szFO41qfH8fkYmrmzYvCbgxe4jzCXqV+8loRVu50d8jGF4E80Pn6atOCCtAXkvbz l+FfcgIdbpjhGliF3mBrrRDW79TKeTgLv5hE0m/vS55h+TR5imqdoHiQfuDJJjWYOxYI Q9jXrGG5+y6LmpwYGlYE3KZQbuzKfEwHhTDuaDHiHtjgXDjfUKcCe9JXNKQIR/0WgBI7 SJ4DwMeB4PiN36O3vfKO7wlCncqIVuw9xmtIYFkvXaxKJV5T1j+NrXnLzi1fCKtpYAOv K194QxXmZ2eV4YlCdjSWBmLwiuBddr/3DGJjVMMylSUat3c15fcKh+kfbHLhoCZCapVH BJxA== MIME-Version: 1.0 X-Received: by 10.152.203.233 with SMTP id kt9mr2192746lac.29.1382368677909; Mon, 21 Oct 2013 08:17:57 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Mon, 21 Oct 2013 08:17:57 -0700 (PDT) In-Reply-To: <5262BDF5.8010507@informatik.haw-hamburg.de> References: <20131019163218.9669.48052.idtracker@ietfa.amsl.com> <5262BDF5.8010507@informatik.haw-hamburg.de> Date: Mon, 21 Oct 2013 10:17:57 -0500 Message-ID: From: Behcet Sarikaya To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=001a11345984fed9ab04e941c99f Cc: "multimob@ietf.org" Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-source-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:18:15 -0000 --001a11345984fed9ab04e941c99f Content-Type: text/plain; charset=ISO-8859-1 Thanks Thomas for the revision. Let me read it and then we will issue a WGLC. Regards, Behcet On Sat, Oct 19, 2013 at 12:14 PM, Thomas C. Schmidt < schmidt@informatik.haw-hamburg.de> wrote: > Hi folks, > > we have eliminated the sub-clause objected by Cong ... the draft should be > fully ready for WGLC, now. > > Thomas > > > A new version of I-D, draft-ietf-multimob-pmipv6-**source-06.txt > has been successfully submitted by Thomas C. Schmidt and posted to the > IETF repository. > > Filename: draft-ietf-multimob-pmipv6-**source > Revision: 06 > Title: Mobile Multicast Sender Support in Proxy Mobile IPv6 > (PMIPv6) Domains > Creation date: 2013-10-19 > Group: multimob > Number of pages: 26 > URL: http://www.ietf.org/internet-**drafts/draft-ietf-multimob-** > pmipv6-source-06.txt > Status: http://datatracker.ietf.org/**doc/draft-ietf-multimob-** > pmipv6-source > Htmlized: http://tools.ietf.org/html/**draft-ietf-multimob-pmipv6-** > source-06 > Diff: http://www.ietf.org/rfcdiff?**url2=draft-ietf-multimob-** > pmipv6-source-06 > > Abstract: > Multicast communication can be enabled in Proxy Mobile IPv6 domains > via the Local Mobility Anchors by deploying MLD proxy functions at > Mobile Access Gateways, via a direct traffic distribution within an > ISP's access network, or by selective route optimization schemes. > This document describes the support of mobile multicast senders in > Proxy Mobile IPv6 domains for all three scenarios. Protocol > optimizations for synchronizing PMIPv6 with PIM, as well as a peering > function for MLD Proxies are defined. Mobile sources always remain > agnostic of multicast mobility operations. > > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --001a11345984fed9ab04e941c99f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Thomas for the revision.

Let me read it and then we will issue a WGLC.

Regards,
Behcet


On Sat, Oct 19, 2013 at 12:14 PM, Thomas C. Schmidt <<= a href=3D"mailto:schmidt@informatik.haw-hamburg.de" target=3D"_blank">schmi= dt@informatik.haw-hamburg.de> wrote:
Hi folks,

we have eliminated the sub-clause objected by Cong ... the draft should be = fully ready for WGLC, now.

Thomas


A new version of I-D, draft-ietf-multimob-pmipv6-source-06.txt
has been successfully submitted by Thomas C. Schmidt and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-multimob-pmipv6-source
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Mobile Multicast Sender Support in Proxy Mobile = IPv6 (PMIPv6) Domains
Creation date: =A0 2013-10-19
Group: =A0 =A0 =A0 =A0 =A0 multimob
Number of pages: 26
URL: http://www.ietf.org/internet-dr= afts/draft-ietf-multimob-pmipv6-source-06.txt
Status: http://datatracker.ietf.org/doc/draft-i= etf-multimob-pmipv6-source
Htmlized: http://tools.ietf.org/html/draft-ietf-m= ultimob-pmipv6-source-06
Diff: http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-multimob-pmipv6-source-06

Abstract:
=A0 =A0Multicast communication can be enabled in Proxy Mobile IPv6 domains<= br> =A0 =A0via the Local Mobility Anchors by deploying MLD proxy functions at =A0 =A0Mobile Access Gateways, via a direct traffic distribution within an<= br> =A0 =A0ISP's access network, or by selective route optimization schemes= .
=A0 =A0This document describes the support of mobile multicast senders in =A0 =A0Proxy Mobile IPv6 domains for all three scenarios. =A0Protocol
=A0 =A0optimizations for synchronizing PMIPv6 with PIM, as well as a peerin= g
=A0 =A0function for MLD Proxies are defined. =A0Mobile sources always remai= n
=A0 =A0agnostic of multicast mobility operations.






Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--001a11345984fed9ab04e941c99f-- From sarikaya2012@gmail.com Thu Oct 24 13:49:26 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25D11E8387 for ; Thu, 24 Oct 2013 13:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv4gUt-pKKgq for ; Thu, 24 Oct 2013 13:49:25 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B04FD11E8384 for ; Thu, 24 Oct 2013 13:49:21 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w7so54589lbi.4 for ; Thu, 24 Oct 2013 13:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zYUpWdC2FAqQWVer+OsV5Z4tJdSi51BPCHU+gQl5Ts0=; b=zyD1Zu7Sbvo67hl9L7xUXMU1xN1FUMRyxgsPECC8ammU1K+vwBv4sIagAJf957qXif DI/cYVoum1WGbNSimha8YzvhMx+LLHDOfqpsPvFRq5iaV6pfm8RJkBd2JpFtY9Yt4pqb oIOsF0Z1aMst5hefNyNKhBc2zNLBCTDICUyvcSmu/w4XBLJVH+O/QrCs2EQUKgaraiJv OhQvDVNjlUONnzr1mAh5HmlFguQeLXbbMDQDwxUkrfAyKhMaR8IUyJveijX7wVs3K35e nnaz4S7oDe5wdshBvAaxdNRj8Uq0w7Z5q/aGmlDnQ6Hzu3w+Uri/RngJkP4pQAFaS32X a9+g== MIME-Version: 1.0 X-Received: by 10.152.179.170 with SMTP id dh10mr2980839lac.14.1382647755729; Thu, 24 Oct 2013 13:49:15 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Thu, 24 Oct 2013 13:49:15 -0700 (PDT) In-Reply-To: References: <20131019163218.9669.48052.idtracker@ietfa.amsl.com> <5262BDF5.8010507@informatik.haw-hamburg.de> Date: Thu, 24 Oct 2013 15:49:15 -0500 Message-ID: From: Behcet Sarikaya To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=001a11349f9e546f8504e982c4be Cc: "multimob@ietf.org" Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-source-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:49:26 -0000 --001a11349f9e546f8504e982c4be Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, authors, Here are my comments on this draft. You can take it as part of WGLC comments. WGLC will be issued shortly. abstract and introduction selective route optimization schemes - add using multicast tree mobility anchor or multicast capable LMA Figs 1 & 2 - change their placement and reformat, this may lead to the whole figure in one page Sec. 3.2.2 - to enable multicast data transition from an MN - replace transition with transmission? Sec. 3.2.3.1 sending PIM registers to the RP - this is explained in Sec. 4.3.2, add pointer RPF (Reverse Path Forwarding) - Reverse Path Forwarding (RPF) BIDIR PIM - BIDIR-PIM Sec. 3.2.4 the multicast routing information base (MRIB) of the MAG - I thought this was not possible? later on seems to be clarified in Sec. 4.3 & 4.4 (I mean according to our face-to-face conversations in the past?) Sec. 3.2.5 There is no mechanism to suppress upstream forwarding in the absence of receivers. - this is solved in Sec. 5, add a pointer to the section that brings some solution Sec. 4.3 4.4 & Fig. 3 (b) see comment above on PIM at MAG Sec. 4.3.6 should be subsection of 4.3.5? Sec. 5.3 Operations at the Multicast Sender - the operation described here is not performed by the MN which is the multicast source/sender, so clarify same in Sec. 5.4. Operations at the Multicast Listener Sec. 5.4 ASM with IGMPv3/MLDv2 - why not have this discussion in the first case, i.e. ASM with IGMPv2/MLDv1? Fig. 1 caption is too long - shorten it and carry the text to Sec. 3.1. In the abstract, This document describes the support of mobile multicast senders - This document describes an experimental protocol to support mobile multicast senders Regards, Behcet On Mon, Oct 21, 2013 at 10:17 AM, Behcet Sarikaya wrote: > Thanks Thomas for the revision. > > Let me read it and then we will issue a WGLC. > > Regards, > > Behcet > > > On Sat, Oct 19, 2013 at 12:14 PM, Thomas C. Schmidt < > schmidt@informatik.haw-hamburg.de> wrote: > >> Hi folks, >> >> we have eliminated the sub-clause objected by Cong ... the draft should >> be fully ready for WGLC, now. >> >> Thomas >> >> >> A new version of I-D, draft-ietf-multimob-pmipv6-**source-06.txt >> has been successfully submitted by Thomas C. Schmidt and posted to the >> IETF repository. >> >> Filename: draft-ietf-multimob-pmipv6-**source >> Revision: 06 >> Title: Mobile Multicast Sender Support in Proxy Mobile IPv6 >> (PMIPv6) Domains >> Creation date: 2013-10-19 >> Group: multimob >> Number of pages: 26 >> URL: http://www.ietf.org/internet-**drafts/draft-ietf-multimob-** >> pmipv6-source-06.txt >> Status: http://datatracker.ietf.org/**doc/draft-ietf-multimob-** >> pmipv6-source >> Htmlized: http://tools.ietf.org/html/**draft-ietf-multimob-pmipv6-** >> source-06 >> Diff: http://www.ietf.org/rfcdiff?**url2=draft-ietf-multimob-** >> pmipv6-source-06 >> >> Abstract: >> Multicast communication can be enabled in Proxy Mobile IPv6 domains >> via the Local Mobility Anchors by deploying MLD proxy functions at >> Mobile Access Gateways, via a direct traffic distribution within an >> ISP's access network, or by selective route optimization schemes. >> This document describes the support of mobile multicast senders in >> Proxy Mobile IPv6 domains for all three scenarios. Protocol >> optimizations for synchronizing PMIPv6 with PIM, as well as a peering >> function for MLD Proxies are defined. Mobile sources always remain >> agnostic of multicast mobility operations. >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> ______________________________**_________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/**listinfo/multimob >> > > --001a11349f9e546f8504e982c4be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas, authors,

Here are my com= ments on this draft. You can take it as part of WGLC comments. WGLC will be= issued shortly.

abstract and introduction
selective route optimi= zation schemes - add using multicast tree mobility anchor or multicast capa= ble LMA

Figs 1 & 2=A0 - change their placement and reformat, this may lead = to the whole figure in one page

Sec. 3.2.2 - to enable multicast dat= a
=A0=A0 transition from an MN=A0 - replace transition with transmission= ?

Sec. 3.2.3.1 sending
=A0=A0 PIM registers to the RP - this is explai= ned in Sec. 4.3.2, add pointer
=A0=A0
RPF (Reverse Path Forwarding) = - Reverse Path Forwarding (RPF)

BIDIR PIM - BIDIR-PIM

Sec. 3.= 2.4
the multicast
=A0=A0 routing information base (MRIB) of the MAG - I thou= ght this was not possible? later on seems to be clarified in Sec. 4.3 &= 4.4 (I mean according to our face-to-face conversations in the past?)
= =A0=A0
Sec. 3.2.5
There is no mechanism to suppress upstream
=A0=A0=A0=A0= =A0 forwarding in the absence of receivers. - this is solved in Sec. 5, add= a pointer to the section that brings some solution
=A0=A0=A0=A0=A0
= Sec. 4.3 4.4 & Fig. 3 (b)
=A0see comment above on PIM at MAG

Sec. 4.3.6 should be s= ubsection=A0 of 4.3.5?

Sec. 5.3 Operations at the Multicast Sender -= the operation described here is not performed by the MN which is the multi= cast source/sender, so clarify

same in Sec. 5.4. Operations at the Multicast Listener

Sec. 5.4<= br>ASM with IGMPv3/MLDv2=A0 - why not have this discussion in the first cas= e, i.e. ASM with IGMPv2/MLDv1?

Fig. 1 caption is too long - shorten = it and carry the text to Sec. 3.1.

In the abstract,
This document describes the support of mobile mult= icast senders - This document describes an experimental protocol to support= mobile multicast senders

Regards,

Behcet
On M= on, Oct 21, 2013 at 10:17 AM, Behcet Sarikaya <sarikaya2012@gmail.com= > wrote:
Thanks Thomas for the revision.

Let me read it and then= we will issue a WGLC.

Regards,

Behcet


On Sat, Oct 19, 2013 at 12:14 PM, Thomas C. Schmidt <<= a href=3D"mailto:schmidt@informatik.haw-hamburg.de" target=3D"_blank">schmi= dt@informatik.haw-hamburg.de> wrote:
Hi folks,

we have eliminated the sub-clause objected by Cong ... the draft should be = fully ready for WGLC, now.

Thomas


A new version of I-D, draft-ietf-multimob-pmipv6-source-06.txt
has been successfully submitted by Thomas C. Schmidt and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-multimob-pmipv6-source
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Mobile Multicast Sender Support in Proxy Mobile = IPv6 (PMIPv6) Domains
Creation date: =A0 2013-10-19
Group: =A0 =A0 =A0 =A0 =A0 multimob
Number of pages: 26
URL: http://www.ietf.org/internet-dr= afts/draft-ietf-multimob-pmipv6-source-06.txt
Status: http://datatracker.ietf.org/doc/draft-i= etf-multimob-pmipv6-source
Htmlized: http://tools.ietf.org/html/draft-ietf-m= ultimob-pmipv6-source-06
Diff: http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-multimob-pmipv6-source-06

Abstract:
=A0 =A0Multicast communication can be enabled in Proxy Mobile IPv6 domains<= br> =A0 =A0via the Local Mobility Anchors by deploying MLD proxy functions at =A0 =A0Mobile Access Gateways, via a direct traffic distribution within an<= br> =A0 =A0ISP's access network, or by selective route optimization schemes= .
=A0 =A0This document describes the support of mobile multicast senders in =A0 =A0Proxy Mobile IPv6 domains for all three scenarios. =A0Protocol
=A0 =A0optimizations for synchronizing PMIPv6 with PIM, as well as a peerin= g
=A0 =A0function for MLD Proxies are defined. =A0Mobile sources always remai= n
=A0 =A0agnostic of multicast mobility operations.






Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob


--001a11349f9e546f8504e982c4be-- From sarikaya2012@gmail.com Fri Oct 25 10:35:51 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5088C11E8365 for ; Fri, 25 Oct 2013 10:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEI+F+rB2qbF for ; Fri, 25 Oct 2013 10:35:50 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAFE11E8360 for ; Fri, 25 Oct 2013 10:35:22 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id eh20so3270546lab.8 for ; Fri, 25 Oct 2013 10:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=CmOY6KQgtB+/IRRAkzdy6Qxtye7U5WuG/mQjsdiq7dM=; b=QRe1F2uSRE1LJ1u7G6acR3GKxoYxvn8zi6nkwtSCgl6Y9nJNG5DXdcFNjVPFkEuWFd stLJbSG5EQe4u5nMIqgsD2irQc5zB/8b1rUpgl3CJNcDEH7LrLhmk1kgHROMsIyuXfOs l0S7lxqRf/EZ62FELDK4N/gxfQDL/a+TdY53Mm2e24g8Nk8CZoiX2V59IcI4fgXUtVTP wgsQJdDsonDOwyC0DbYJDwoqCsaINDv0PZBp78p0R/lBKdlimVK93VA9/gAzQklB4TFz 6gJSs0rkeb85UCHA7Wjh44HZOE7mp4dEb5qCwYQ7oI8qeaRe/2Kc1/u3cj6YYAatl+g/ 03Cg== MIME-Version: 1.0 X-Received: by 10.152.22.97 with SMTP id c1mr2708611laf.31.1382722512674; Fri, 25 Oct 2013 10:35:12 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Fri, 25 Oct 2013 10:35:12 -0700 (PDT) Date: Fri, 25 Oct 2013 12:35:12 -0500 Message-ID: From: Behcet Sarikaya To: "multimob@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b86a30e4b604e9942cef Subject: [multimob] draft-ietf-multimob-pmipv6-source-06 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:35:51 -0000 --089e0158b86a30e4b604e9942cef Content-Type: text/plain; charset=ISO-8859-1 Folks, This message starts a four week Multimob Working Group last call on advancing: Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Author(s) : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-06.txt Pages : 26 Date : 2013-10-19 as Experimental. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on November 22, 2013. Regards, Behcet --089e0158b86a30e4b604e9942cef Content-Type: text/html; charset=ISO-8859-1
Folks,

This message starts a four week 
Multimob Working Group last call
on advancing:


	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
	Author(s)       : Thomas C. Schmidt
                          Shuai Gao
                          Hong-Ke Zhang
                          Matthias Waehlisch
	Filename        : draft-ietf-multimob-pmipv6-source-06.txt
	Pages           : 26
	Date            : 2013-10-19



as Experimental.  Substantive comments and statements of support
for advancing this document should be directed to the mailing list.
Editorial suggestions can be sent to the authors.  This last call will
end on November 22, 2013.
Regards,
Behcet
--089e0158b86a30e4b604e9942cef-- From Dirk.von-Hugo@telekom.de Mon Oct 28 02:54:24 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D411E811A for ; Mon, 28 Oct 2013 02:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIgXZvLqpATL for ; Mon, 28 Oct 2013 02:54:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3A11E8125 for ; Mon, 28 Oct 2013 02:54:08 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 28 Oct 2013 10:54:05 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 28 Oct 2013 10:54:05 +0100 From: To: Date: Mon, 28 Oct 2013 10:54:03 +0100 Thread-Topic: [multimob] draft-ietf-multimob-pmipv6-source-06 Thread-Index: Ac7RqKkZn12pCZJKQTqT0T1224eBcQCGNvIQ Message-ID: <05C81A773E48DD49B181B04BA21A342A2C7571986D@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C7571986DHE113484emea1_" MIME-Version: 1.0 Subject: Re: [multimob] draft-ietf-multimob-pmipv6-source-06 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 09:54:24 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C7571986DHE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I am fine with the current version (beyond already mentioned nits - e.g. I = would suggest to just say for Fig. 1 caption "Reference Network for genera= l Multicast Deployment in PMIPv6") and I support successful WGLC. Thanks to the authors and all providing helpful comments for improvement! Best regards Dirk From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of Behcet Sarikaya Sent: Freitag, 25. Oktober 2013 19:35 To: multimob@ietf.org Subject: [multimob] draft-ietf-multimob-pmipv6-source-06 Folks, This message starts a four week Multimob Working Group last call on advancing: Title : Mobile Multicast Sender Support in Proxy Mobile I= Pv6 (PMIPv6) Domains Author(s) : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-06.txt Pages : 26 Date : 2013-10-19 as Experimental. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on November 22, 2013. Regards, Behcet --_000_05C81A773E48DD49B181B04BA21A342A2C7571986DHE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,=

I am fine with the curren= t version (beyond already mentioned nits – e.g. I would suggest to ju= st say for Fig. 1 caption  “Reference Network for general= Multicast Deployment in PMIPv6”) and I support successful WGL= C.

 

Thanks to the authors and all providing he= lpful comments for improvement!

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Best regards

Dirk

From: multimob-bounces@ietf.org [mail= to:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sen= t: Freitag, 25. Oktober 2013 19:35
To: multimob@ietf.org
<= b>Subject: [multimob] draft-ietf-multimob-pmipv6-source-06

 

Folks,

This message sta=
rts a four week 
Multimob Working Group last call
o=
n advancing:


        Title&nb=
sp;          : Mobile Multicas=
t Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
        Author(s)   &nbs= p;   : Thomas C. Schmidt
   &=
nbsp;           &nbs=
p;          Shuai Gao
           &=
nbsp;           &nbs=
p;  Hong-Ke Zhang
    &n=
bsp;            =
;         Matthias Waehlisch
        Filename &nb=
sp;      : draft-ietf-multimob-pmipv6-source-06.tx=
t
        Pages&nbs=
p;          : 26
        Date   &n=
bsp;        : 2013-10-19
 
 
 
as Experimental.  Substantive comments an=
d statements of support
for advancing this document sh=
ould be directed to the mailing list.
Editorial sugges=
tions can be sent to the authors.  This last call will
end on November 22, 2013.
Regards,
Behcet
= --_000_05C81A773E48DD49B181B04BA21A342A2C7571986DHE113484emea1_-- From Sebastian.Woelke@haw-hamburg.de Mon Oct 28 06:26:37 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694B911E827B for ; Mon, 28 Oct 2013 06:26:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxdNMFCuJ6XQ for ; Mon, 28 Oct 2013 06:26:33 -0700 (PDT) Received: from posteo.de (mail.posteo.de [89.146.220.134]) by ietfa.amsl.com (Postfix) with ESMTP id D10F111E82E0 for ; Mon, 28 Oct 2013 06:26:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTP id 883D4200C9A8F for ; Mon, 28 Oct 2013 14:26:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at posteo.de Received: from posteo.de ([127.0.0.1]) by localhost (posteo.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ykBRhB5fckvR for ; Mon, 28 Oct 2013 14:26:10 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTPSA id 6ADAF20025597 for ; Mon, 28 Oct 2013 14:26:09 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 Oct 2013 14:26:04 +0100 From: Sebastian Woelke To: In-Reply-To: References: Message-ID: <70d4b06bd068b7160026b15b22d2d0f8@posteo.de> X-Sender: Sebastian.Woelke@haw-hamburg.de User-Agent: Posteo Webmail Subject: [multimob] draft-ietf-multimob-pmipv6-source-06 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 13:26:37 -0000 Hi, I've taken a look at the current version of the draft and I think it is well written and in a good shape. Here are two additional comments: 3.1. Overview Figure 1: Local Mobiity Anchor ==> Local Mobility Anchor 4.2.1. Considerations for PIM-SM on the Upstream (see Section Section 3.2.3.1) ==> (see Section 3.2.3.1) Regards, Sebastian > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Freitag, 25. Oktober 2013 19:35 > To: multimob@ietf.org > Subject: [multimob] draft-ietf-multimob-pmipv6-source-06 > > Folks, > > This message starts a four week > Multimob Working Group last call > > on advancing: > > > Title : Mobile Multicast Sender Support in Proxy > Mobile IPv6 (PMIPv6) Domains > > Author(s) : Thomas C. Schmidt > > Shuai Gao > > Hong-Ke Zhang > > Matthias Waehlisch > > Filename : draft-ietf-multimob-pmipv6-source-06.txt > > Pages : 26 > > Date : 2013-10-19 > > > > > > > as Experimental. Substantive comments and statements of support > > for advancing this document should be directed to the mailing list. > > Editorial suggestions can be sent to the authors. This last call > will > > end on November 22, 2013. > > Regards, > > Behcet > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > End of multimob Digest, Vol 77, Issue 18 > ****************************************