On 3/14/14 12:35 AM, "Alvaro Retana (aretana)"
<[email protected]<mailto:[email protected]>> wrote:
[WG Chair hat off.]
Hi!
Please provide specific feedback as to why you support (or not) the advancement
of this draft. Please avoid "+1"-type responses.
I support the publication of this draft. The content is valuable, there are a
few implementations, etc.
However, I think that the organization can be improved to avoid duplication of
some information and to clarify when/where does MoFRR work better (or not).
Please see below for more comments.
Thanks!
Alvaro.
Major issues:
1. Basic Overview. You wrote: "The two divergent paths SHOULD never merge
upstream". Do you really want/need to use "SHOULD" (as in rfc2119) here?
While I don't think anyone can argue that it is a good network design practice,
there is no way (at least not mentioned in the draft) for MoFRR to verify that
the paths are divergent (or not). Also, in the "Topologies for MoFRR" section
you write that "MoFRR works best in topologies illustrated in the figure
below"..but doesn't mandate them. All this is to say that I think that the
"SHOULD" in this section should just say "should".
2. Topologies for MoFRR. Which topologies are not well suited for MoFRR. A
short discussion would help a lot.
3. Security Considerations. I know that the operation of PIM/mLDP is not
changed on the wire, but it is changed locally resulting in a redundant stream.
Not all topologies will result in merging the secondary tree with the primary
at a relatively close point in the topology (as in the examples)..and not all
deployments will have the ability to plan/predict the utilization. All this
could result (in some topologies/deployments) in the inability to offer other
services (because of congestion, for example). Do you consider this a security
issue? A related discussion would help better understand the effect. Note
that this point is related to #2 above, and may be addressed by clearly talking
about the topologies and potential effects.
4. Consider Reordering the Sections. When reading through the document I
felt at times that information maybe should have been presented..and in some
cases the information seemed to be disjoint. For example,
* Section 3 ('Upstream Multicast Hop Selection') presents the basic
selection (no change from PIM/mLDP), but it doesn't explain what to really do
for MoFRR (which is explained in sections 6 ('ECMP-mode MoFRR') and 7
('Non-ECMP-mode MoFRR')).
* Parts of Section 4.1 talk about deployment considerations (why is it
easy to apply MoFRR to the topology), but that information is repeated in
section 8 ('Keep It Simple Principle') and complemented by sections 9
('Capacity Planning for MoFRR') and 5 ('Detecting Failures'). I would suggest
consolidating these operations/deployment oriented sections into a single one.
Minor issues:
1. Introduction. "Multiple techniques have been developed and deployed .."
Which ones? Can you provide a (short) discussion as to why MoFRR is
better/addresses issues not addressed before/etc.?
2. Introduction. "With MoFRR, in many cases, multicast routing protocols
don't necessarily have to depend on or have to wait on unicast routing
protocols to detect network failures." Which are those cases? Maybe a
pointer to the 'Failure Detection' section might be enough.
3. Terminology. Please add "merge point" to the list.
4. Terminology. You defined some acronyms, but not all. I'm thinking that
you should either expand them all in this section or just be clear about them
(specifically the ones that have a definition and are not just an expansion)
where they are first introduced.
5. Section 4.1. You wrote "PEs not enabled for MoFRR do not see any change
or degradation." I'm sure you meant that the PEs where MoFRR is not enabled
won't see any effect resulting from enabling it in other PEs, right? It sounds
as if you meant that the PEs without MoFRR won't see a difference in
performance of the multicast stream/convergence characteristics, etc. when
compared to the ones with it..which would make me think, then why use MoFRR?
;-) Please clarify.
6. Section 4.1. "End-to-end failure detection and recovery.." A pointer to
the 'Detecting Failures' section would be nice.
7. Section 4.1. "(the backup path crosses links/nodes which already carry
the primary/normal tree and hence twice as much capacity is required)" Are you
talking about the "conventional FRR mechanisms" or about MoFRR? In either case
it sounds like you're contradicting yourself.
8. Detecting Failures. In a couple of places you mention that "50msec
switchover is possible". Even though I can see how you're making that
assumption (link down detection time, for example), the part about knowing the
minimum packet rate doesn't make much sense to me because that rate may be
larger than 50ms. Am I missing something? [I know that the general
application is IPTV, see below, but I'm assuming the application is not limited
to that.]
9. ECMP-mode MoFRR. "If more than two ECMP paths exist.." In this
paragraph you suggest that other aspects may be taken into account (such as
looking into the IGP topology), but you're not specific. I realize that the
operation doesn't require interoperability..but it would be nice to either
specify some options or just leave it at "the decision on how to select a
secondary UHM is left to a local decision". The later would be my preference.
10. Non-ECMP-mode MoFRR. "Router X MUST stop joining the seconday path if the
following as described below occurs. . .In order to prevent control-plane loops
a router MUST never setup a secondary path to a LFA UMH if this UMH is the only
member in the OIF list." I think there are really two conditions here (not
just one as the text seems to indicate):
* The secondary path shouldn't be established if the LFA is the only
member of the OIF list.
* The secondary path is established through an LFA (because there are
multiple members in the OIF list), but later a change in the network results in
the secondary UMH being alone in the OIF list.
11. Keep It Simple. This section seems to answer my point #8 above. You
should consider merging the two.
Nits:
1. Abstract. You mention "IPTV deployments", but isn't it any streaming
media application over IP? Maybe just splitting hairs..but a good
intro/abstract is important.
2. Basic Overview. s/'upstream paths at the time'/'upstream paths at a time'
3. Basic Overview. There are a couple of places in this section (when
talking about redundancy and the selection of the UMH) that refer to other
places in the draft. It would be nice if a reference to the specific section
was included.
4. Section 3.2. s/'independent on the interface'/'independent of the
interface'
5. Topologies for MoFRR. "MoFRR works best in topologies illustrated in the
figure below." I think you meant "figures".
6. Dual-Plane Topology. s/its its/its
7. Section 4.1. "..described later in the document.." Pointer to the
section.
8. ECMP-mode MoFRR. s/same as if MoFRR extension/same as if the MoFRR
extension
9. Non-ECMP-mode MoFRR. s/seconday/secondary
10. s/draft-ietf-rtgwg-lfa-applicability/rfc6571
11. Capacity Planning. s/can still benefit from MoFRR benefits/can still
benefit from MoFRR.
12. References to MPLS-OAM, BFD, MVPN..
13. You're missing the 'IANA Considerations' section.
14. References: rfc5036 is not referenced anywhere.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
