Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 6 Sep 2013 20:14:48 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Thomas C. Schmidt
Sent: Monday, August 26, 2013 4:29 PM
To: [email-masked]
Cc: [email-masked]
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-masked] 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-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Samstag, 13. Juli 2013 00:50
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/multimob
> _______________________________________________
> multimob mailing list
> [email-masked]
> 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-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 30 Sep 2013 01:06:17 +0200

Hi Dirk,

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

On 26.08.2013 18:29, [email-masked] wrote:

> 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.

> 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.

> 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.

>     function for MLD Proxies are defined.

Thanks, corrected.

> ==> 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 applications for mobile multicast reception of content from few and mainly fixed content sources
>
> p.5
>

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
O.K., fixed.

> 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 (Reverse Path Forwarding)

O.K., fixed.

> 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.

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

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.

> configurations have completed => configurations have been completed

o.k.

>     same next-hop router using the same source address
> =>  traffic from the mobile source continues to be transmitted via the

o.k.

> ==> 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.

>     unicast routes ( see Fig. 3(b)).

O.K.

> =>  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.

>     (tunnel) interface and thus (?) immediately respond with a register stop.

O.k., fixed.

>     RP has joined the shortest path tree to receive data from the source via

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.

>     receivers eventually will initiated a source-specific Join for
> => In response to an exceeded threshold of packet transmission, DRs of

Thanks, fixed.

>     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

thanks, o.k.

> => 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.

> ==> 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.

> ==> 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 s…

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:

O.k., reworded.

> ==> to me there seem to be no IANA activities arising from the proposed protocol modifications, right?

Yes.

> the PMIPv6 domain will in general not actively terminate group membership prior

o.k.

> 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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
>
>

--

---

From: Cong Liu <[email-masked]>
Date: Mon, 30 Sep 2013 14:47:22 +0800

Dear all,

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.

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!

Best Regards,
Cong Liu

2013/9/30 Thomas C. Schmidt <[email-masked]>

>  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 ...
>>
>> Multicast support at MAG level or above via different established Multicast
>> protocols (sect.4)
>> (sect. 5)
>  I have some comments and suggestions to increase readability, in addition
>> to some nits found, given in the following:
>>
>  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 ...
>>
>
>> ==> 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  ...?
>>
>>
>> ==> 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 .
>>
>
> that a mulitcast unaware reader will not succeed in taking profit from this
> document ;)
>
>
>> ... 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
>> => In the following, efficiency-related issues which remain unsolved
>> within the above defined base PMIPv6 multicast source support are described.
>>
>>
>> ==> 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
>>
>
>> ==> to me it seems to be one solution only (peering between MLD proxies)
>> adapted to several multicast protocol implementations for ASM and SSM
>>
>>
>> ==> 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
>> From: [email-masked] [mailto:multimob-bounces@ietf.**org<[email-masked]>]
>> On Behalf Of [email-masked]
>> Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-**
>> source-04.txt
>>
>>
>>         Filename        : draft-ietf-multimob-pmipv6-**source-04.txt
>>         Pages           : 24
>>         Date            : 2013-07-12
>>
>> Abstract:
>> https://datatracker.ietf.org/**doc/draft-ietf-multimob-**pmipv6-source<https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>>
>> http://tools.ietf.org/html/**draft-ietf-multimob-pmipv6-**source-04<http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>>
>> http://www.ietf.org/rfcdiff?**url2=draft-ietf-multimob-**pmipv6-source-04<http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04>
>>
>>
>> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>
>> ______________________________**_________________
>> multimob mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>>
>>
> --
>
> ° http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/~schmidt>   Fax: +49-40-42875-8409 °
> ______________________________**_________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 30 Sep 2013 14:08:03 +0200

Dear Cong Liu,

thanks for your feedback - please see inline.

On 30.09.2013 08:47, Cong Liu wrote:

> 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.

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.

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."

> Some nits:
> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy
> or MLD Proxy

Thanks, it's fixed.

Best regards,

Thomas

> Thanks!
>
> Best Regards,
> Cong Liu
>
>
> 2013/9/30 Thomas C. Schmidt <[email-masked]
> <mailto:[email-masked]>>
>
>     Hi Dirk,
>
>     On 26.08.2013 18:29, [email-masked]
>     <mailto:[email-masked]> 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 ...
>
>         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)
>         I have some comments and suggestions to increase readability, in
>         addition to some nits found, given in the following:
>
>         Is there any implicit meaning of Proxy with respect to proxy?
>         Also MLD Proxy and MLD proxy are both used throughout the
>         document ...
>
>
>         [I-D.ietf-multimob-pmipv6-__ropt],
>         draft-ietf-multimob-fmipv6-__pfmipv6-multicast,
>         draft-ietf-multimob-handover-__optimization  ...?
>
>
>         => needs of applications for mobile multicast reception of
>         content from few and mainly fixed content sources
>
>         p.5
>
>         ==> 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 ;)
>
>
>     Mhmm, my dictionary says "data is" ... "data" is a singular term
>     that subsumes (uncountable) plural ...
>
>
>         p.8
>         ... 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
>         => For a dual-stack IPv4/IPv6 access network, the MAG proxy
>         instances (i.e. IPMP/MLD proxy functions)
>
>         => In the following, efficiency-related issues which remain
>         unsolved within the above defined base PMIPv6 multicast source
>         support are described.
>
>
>             BIDIR-PIM MAY be deployed in the access network =>
>           BIDIR-PIM [RFC5015] MAY be deployed in the access network
>
>
>         ==> 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.
>
>         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.
>
>         ==> 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
>         From: [email-masked]
>         <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of
>         [email-masked] <mailto:[email-masked]>
>         To: [email-masked] <mailto:[email-masked]>
>         Cc: [email-masked] <mailto:[email-masked]>
>         draft-ietf-multimob-pmipv6-__source-04.txt
>
>
>                  Filename        :
>         draft-ietf-multimob-pmipv6-__source-04.txt
>                  Pages           : 24
>                  Date            : 2013-07-12
>
>         Abstract:
>         https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source
>         <https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>
>         http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04
>         <http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>
>         http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04
>         <http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04>
>
>
>         ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         _________________________________________________
>         multimob mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/multimob
>         <https://www.ietf.org/mailman/listinfo/multimob>
>
>
>     --
>
>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>     +49-40-42875-8409 °
>     _________________________________________________
>     multimob mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/multimob
>     <https://www.ietf.org/mailman/listinfo/multimob>
>
>

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 30 Sep 2013 14:48:19 +0200

Hi Akbar,

many thanks for the review. Please see answers inline:

> - Can you put a reference for the 3rd paragraph?

O.K., done.

> - The word "enfold" in 4th paragraph does not seem grammatically correct in the given sentence.  Perhaps use another word?

Right ... we put "develop".

> - 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?

For gaming we need to ask the kids ;) ... anyway, the story or 
architecture is simple and straight forward: The game server holds the 
entire state of the game and may distribute this via multicast. 
Individual feedback is unicast (client -> server).

> - 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.

O.K., we added that to the caption ... makes it lengthy, but easier to 
comprehend.

> - 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?

Mmcast sources are in a different picture, here mcast traffic arrives 
first from a local source. In 6224, not Mcast data, but MLD reports 
arrive at the MAGs. Those are equally discarded in the absence of 
multicast capabilities (i.e., a proxy), but for different reasons 
(because these are link-local signaling packets).

> - 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…

Yes, I agree. The Security Section was reworked anyway ... this was only 
incomplete sample text.

Best regards,

Thomas

--

---

From: <[email-masked]>
Date: Mon, 30 Sep 2013 15:51:48 +0200

Hi Thomas and co-authors,
Thank you for the effort.
I am fine with the changes and all other improvements introduced in v05 and agree that we could go for WGLC now ...
Best regards
Dirk

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Montag, 30. September 2013 01:06
To: von Hugo, Dirk
Cc: [email-masked]
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt

Hi Dirk,

Yes, this is it.

> 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.

Thanks, corrected.

> ==> 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 corr…

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 ;)

O.K., fixed.

O.K., fixed.

O.K., fixed.

O.K., fixed.

o.k.

o.k.

o.k.

O.K.

O.K.

Thanks, o.k.

o.k.

O.k., fixed.

Meanwhile replaced.

s.o.

Thanks, fixed.

o.k.

thanks, o.k.

Thanks, o.k.

Thanks, fixed.

o.k., thanks.

O.k., we've added this.

thanks, fixed.

O.k., reworded.

Yes.

o.k.

Thanks, fixed.

Best wishes,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Mon, 30 Sep 2013 12:19:45 -0700

Hi

> 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.

> to the RP would cause duplicate (S,G) traffic arriving at the

No, that shouldn't happen.

>     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.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 30 Sep 2013 22:37:25 +0200

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 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.

> 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.

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

> 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?

Cheers,

Thomas

--