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:[email protected]] On Behalf Of Alvaro Retana
> (aretana)
> Sent: Thursday, March 27, 2014 9:57 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: WGLC for draft-ietf-rtgwg-mofrr
>
> On 3/14/14 12:35 AM, "Alvaro Retana (aretana)" <[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, 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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
