Hi Thomas,
I also reviewed draft-ietf-multimob-pmipv6-source-04 and following is my feedback/ Overall the I-D is in very nice shape and I think ready to progress to the next stage. I only had a few comments for you to take into consideration (beyond the thorough review that Dirk already did). 1) Section 1 (Introduction) - Can you put a reference for the 3rd paragraph? - The word "enfold" in 4th paragraph does not seem grammatically correct in the given sentence. Perhaps use another word? - I am not a big gamer, so can you please explain why a "server-centric gaming" is multicast listener only? How can you have a game without user feedback? 2) Section 3.1 (Overview) - Do you think it would be worthwhile explaining the acronyms (notations) in Figure 1 (e.g. LMAA1, MN-HNP1, etc.)? The meaning of some are not obvious. - One question on "MRIB". In this I-D it seems to be a key concept, but why was there no mention of it in RFC 6224? 3) Section 9 (Security Considerations) - Remove the "TODO" - I don't think the wording of the 1st paragraph is good. I think that there definitely is a new threat introduced with the support of mobile multicast senders. For example, wouldn't there be new modes of Denial of Service attacks? For example, if flash mobs of mobile attackers appeared in certain localized areas (e.g. WiFi hotspot, cellular BS) and generated high amounts of multicast sender traffic. I don't think that this type of attack was possible with RFC 6224. Do you agree? Best Regards, Akbar -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas C. Schmidt Sent: Monday, August 26, 2013 4:29 PM To: [email protected] Cc: [email protected] Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt Hi Dirk, thanks for your thorough review. I'll come back to this in detail a few days. Best regards, Thomas On 26.08.2013 18:29, [email protected] wrote: > Dear all, > 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? > IMHO from the abstract this is not easily to see. > > 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. > 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 ... > > 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. > > 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 ...? > > 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 . > > In case of a handover, the MN (unaware of IP mobility) => In case of a > handover, the MN (being unaware of IP mobility) > > as soon as network connectivity is > reconfigured > => as soon as network connectivity is > re-established > > p.7 > multicast data is => multicast data are > > 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 > > incoming interface validation is only performed by RPF > checks > => incoming interface validation is only performed by RPF (Reverse Path > Forwarding) > checks > > 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?! > > 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. > > p.11 > upstream will lead traffic into the multicast infrastructure => > upstream will transfer traffic into the multicast infrastructure > > p.12 > configurations have completed => configurations have been completed > > 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 > > by aggregating proxies on a lower layer. > ==> please clarify: what layer exactly is proposed? PIM DR at MAGs? > > 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)). > > 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]. > > P.14 > configured to not initiated (S,G) shortest path tress for mobile => > configured to not initiated (S,G) shortest path trees for mobile > > mobile source. This tree can be of lesser routing efficiency than => > mobile source. This tree can be of lower routing efficiency than > > 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. > > 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, > > 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 > > 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 > > 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?) > > 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 > > p.15 > via the source register tunnel. Tree mainenance eventually triggered > => via the source register tunnel. Tree maintenance eventually > triggered > > p.16 > BIDIR-PIM MAY be deployed in the access network => BIDIR-PIM > [RFC5015] MAY be deployed in the access network > > remain uneffected by node mobility => remain unaffected by node > mobility > > spanning group tree => spanning tree for the multicast group > /multicast spanning tree > > 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 > > 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 > > 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? > > p.18 > This filter base Must be updated, if and => This filter base MUST be > updated, if and > > 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 > > p.19 > 6. IANA Considerations > TODO. > ==> to me there seem to be no IANA activities arising from the proposed > protocol modifications, right? > > 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. > > p.22 > but alternate configuriations => but alternate configurations > > a state decomposition , if needed => a state decomposition, if needed... > > Hope this helps. > Thanks! > > Best regards > Dirk > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > Sent: Samstag, 13. Juli 2013 00:50 > To: [email protected] > Cc: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
