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

[Stig Venaas <[e-mail]>]

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 <[e-mail]
>>>> <mailto:[e-mail]>>
>>>>
>>>>     Hi Dirk,
>>>>
>>>>     thanks again for your detailed comments. Please see replies inline.
>>>>
>>>>     On 26.08.2013 18:29, [e-mail]
>>>>     <mailto:[e-mail]> 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: [e-mail]
>>>>         <mailto:[e-mail]>
>>>>         [mailto:multimob-bounces@ietf.__org
>>>>         <mailto:[e-mail]>] On Behalf Of
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         Sent: Samstag, 13. Juli 2013 00:50
>>>>         To: [e-mail] <mailto:[e-mail]>
>>>>         Cc: [e-mail] <mailto:[e-mail]>
>>>>         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
>>>>
>>>> <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
>>>>
>>>> <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
>>>>
>>>>
>>>>
>>>> <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/
>>>>         <ftp://ftp.ietf.org/internet-drafts/>
>>>>
>>>>         _________________________________________________
>>>>         multimob mailing list
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://www.ietf.org/mailman/__listinfo/multimob
>>>>         <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:
>>>>     [phone] °
>>>>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>>>>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>>>>     [phone] °
>>>>     _________________________________________________
>>>>     multimob mailing list
>>>>     [e-mail] <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/__listinfo/multimob
>>>>     <https://www.ietf.org/mailman/listinfo/multimob>
>>>>
>>>>
>>>
>>
>