Thanks!
Best Regards,
Cong Liu
2013/9/30 Thomas C. Schmidt <[email protected]
<mailto:[email protected]>>
Hi Dirk,
thanks again for your detailed comments. Please see replies inline.
On 26.08.2013 18:29, [email protected]
<mailto:[email protected]> 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: [email protected]
<mailto:[email protected]>
[mailto:multimob-bounces@ietf.__org
<mailto:[email protected]>] On Behalf Of
[email protected] <mailto:[email protected]>
Sent: Samstag, 13. Juli 2013 00:50
To: [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[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
<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
[email protected] <mailto:[email protected]>
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:
+49-40-42875-8452 °
° http://www.informatik.haw-__hamburg.de/~schmidt
<http://www.informatik.haw-hamburg.de/~schmidt> Fax:
+49-40-42875-8409 °
_________________________________________________
multimob mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/multimob
<https://www.ietf.org/mailman/listinfo/multimob>
