Re: WGLC for draft-ietf-rtgwg-mofrr

["Alvaro Retana (aretana)" <[e-mail]>]

On 3/14/14 12:35 AM, "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>> 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.