Otherwise you need to provide references.
Regards,
Behcet
On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas <[email protected]
<mailto:[email protected]>> 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
<[email protected]__hamburg.de
<mailto:[email protected]>
<mailto:schmidt@informatik.__haw-hamburg.de
<mailto:[email protected]>>>
Hi Dirk,
thanks again for your detailed comments. Please
see replies inline.
On 26.08.2013 18 <tel:26.08.2013%2018>:29,
[email protected]
<mailto:[email protected]>
<mailto:Dirk.von-Hugo@telekom.__de
<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]>>
[mailto:multimob-bounces@ietf.
<mailto:multimob-bounces@ietf.>____org
<mailto:multimob-bounces@ietf.__org
<mailto:[email protected]>>] On Behalf Of
[email protected]
<mailto:[email protected]>
<mailto:internet-drafts@ietf.__org
<mailto:[email protected]>>
Sent: Samstag, 13. Juli 2013 00:50
To: [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
Cc: [email protected]
<mailto:[email protected]> <mailto:[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>
<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>
<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>
<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/>
<ftp://ftp.ietf.org/internet-__drafts/
<ftp://ftp.ietf.org/internet-drafts/>>
___________________________________________________
multimob mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
https://www.ietf.org/mailman/____listinfo/multimob
<https://www.ietf.org/mailman/__listinfo/multimob>
<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 <tel:%2B49-40-42875-8452> °
°
http://www.informatik.haw-____hamburg.de/~schmidt
<http://www.informatik.haw-__hamburg.de/~schmidt>
<http://www.informatik.haw-__hamburg.de/~schmidt
<http://www.informatik.haw-hamburg.de/~schmidt>> Fax:
+49-40-42875-8409 <tel:%2B49-40-42875-8409> °
___________________________________________________
multimob mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
https://www.ietf.org/mailman/____listinfo/multimob
<https://www.ietf.org/mailman/__listinfo/multimob>
<https://www.ietf.org/mailman/__listinfo/multimob
<https://www.ietf.org/mailman/listinfo/multimob>>
_________________________________________________
multimob mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/multimob
<https://www.ietf.org/mailman/listinfo/multimob>
