RE: WGLC for draft-ietf-rtgwg-mofrr

[<[e-mail]>]

Hi Alvaro,

Many thanks for your in depth review of the draft. It has been really helpful to improve the document.

We have just published v04 which should address your comments.

Please find below the answer to each of your comments.

Ice, Bruno
---

> 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.

Agreed.
Section "5. Detecting Failures" has been moved to section 4, just after the determination of the backup upstream (section 3 Upstream Multicast Hop Selection). This is to group the specification text together.

> 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".

Agreed that "SHOULD" is not required.

OLD: The two divergent paths SHOULD never merge upstream
NEW: In order maximize robustness against any failure, the two paths should be as diverse as possible. Ideally, they should not merge upstream.

> 2.        Topologies for MoFRR.  Which topologies are not well suited for MoFRR.  A short discussion would help a lot.

Agreed. A section "MoFRR applicability" has been added which discuss the applicability of MoFRR depending on the topology.
Author Response: The text of this section was mostly already present in the draft, but used to be split in multiple sections, which I agree was no optimal for the reader.

>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.

Author Response: I don't think this is a security consideration. MoFRR is a service that is applied to the network by the operator, and which links carry traffic is depending on where receivers are joining from. The fact that you don't know in which parts of the network multicast receivers will join is not considered a security concern either, right?


>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,  
> o         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')).
> o         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.

Author Response: Agreed. The sections have been reorganized as follow:

- Section 2 "Basic Overview" provides the overview of the solution, including pointers to the sections providing the details
- Section 3 "Determination of the secondary UMH" defines how the alternate UMH is found. In the general case and with a focus on ECMP and ECMP cases.
- Section 4 "Upstream Multicast Hop Selection" defines which UMH should be used for forwarding.
- Section 5 "Detecting failures" discusses multiple options to detect the failure (either locally or end to end)
- Section 6 "MoFRR applicability" discusses the applicability of MoFRR depending on the network topology.

So sections 2 to 4 are intended to be normative, while sections 5 to 6 are more informational.


> 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.?

Author Response: Reworked the text, the reasons its better is explained later on in the text, i.e. no changes to the protocols.

>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.
Author Response: Done.

>3.         Terminology.  Please add "merge point" to the list.
Author Response: Done.

>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.

Author Response: Updated the Terminology section.

> 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.

Author Response: I removed that sentence as the previous one was enough ("Each PE device can be enabled one by one".)

> 6.        Section 4.1. "End-to-end failure detection and recovery.."  A pointer to the 'Detecting Failures' section would be nice.

Author Response: Agreed. Done

> 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.

This sentence was talking about conventional FRR. The sentence has been changed to make this clearer: "This is different from conventional FRR mechanisms which often duplicate the capacity requirements when the backup path crosses links/nodes which already carry the primary/normal tree and hence twice as much capacity is required."

That been clarified, I'm not seeing the contradiction. Could you please point it out?

> 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.]

Author Response: Agreed.

For the first option (local link failure detection), a reference to unicast FRR performance "50 ms" has been added:
OLD: 50msec switchover is possible.
NEW: Just like for unicast fast reroute, 50msec switchover is possible.

Author Response: For the third option (detecting the absence of the multicast stream), the dependency on the multicast rate has been added:
OLD: 50msec switchover may be possible.
NEW: 50msec switchover may be possible for high rate stream (e.g. IP TV) but in general the delay is dependant on the rate of the multicast stream.

> 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.

Author Response: Updated.

> 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): 
> o         The secondary path shouldn't be established if the LFA is the only member of the OIF list.
> o         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.

Author Response: Indeed. However, the first point seems implicit: a router will not compute an alternate if there is no nominal. We have rephrased to "In order to prevent control-plane loops a router MUST stop joining the secondary UMH if this UMH is the only member in the OIF list." Do you think this is clear enough?


>11.       Keep It Simple.  This section seems to answer my point #8 above.  You should consider merging the two.

Author Response: That section has been removed and the text moved in other section (cf the above point about section reorganisation)

> 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.

Author Response: Not sure what you mean here.

> 2.        Basic Overview. s/'upstream paths at the time'/'upstream paths at a time'

Author Response: Done.

> 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.

Author Response: Agreed. Done. One additional reference has also been added, so that this overview can be read as an overview introducing and pointing to the different section of the document.

> 4.        Section 3.2. s/'independent on the interface'/'independent of the interface'

Author Response: Done.

> 5.        Topologies for MoFRR.  "MoFRR works best in topologies illustrated in the figure below."  I think you meant "figures".

Author Response: Done.

> 6.        Dual-Plane Topology. s/its its/its

Author Response: Done.

>7.         Section 4.1. "..described later in the document.."  Pointer to the section.

Author Response: Done.

> 8.        ECMP-mode MoFRR. s/same as if MoFRR extension/same as if the MoFRR extension

Author Response: Done.

> 9.        Non-ECMP-mode MoFRR.  s/seconday/secondary

Author Response: Done.

> 10.      s/draft-ietf-rtgwg-lfa-applicability/rfc6571

Author Response: Done.

> 11.      Capacity Planning. s/can still benefit from MoFRR benefits/can still benefit from MoFRR.

Author Response: Done.

>12.       References to MPLS-OAM, BFD, MVPN..

Author Response: Done

> 13.      You're missing the 'IANA Considerations' section.

Author Response: Done (no IANA request)

> 14.      References:  rfc5036 is not referenced anywhere.

Author Response: Done.


> -----Original Message-----
> From: rtgwg [mailto:[e-mail]] On Behalf Of Alvaro Retana
> (aretana)
> Sent: Thursday, March 27, 2014 9:57 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: WGLC for draft-ietf-rtgwg-mofrr
> 
> On 3/14/14 12:35 AM, "Alvaro Retana (aretana)" <[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, o 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')).
> o 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):
> o The secondary path shouldn't be established if the LFA is the only member
> of the OIF list.
> o 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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.