Hi!
Happy New Year!
I just finished reviewing this document. I have several comments (please see
below) that I want to see addressed before starting the IETF Last Call.
Out of the items marked as Major, the one that concerns me the most is the one
related to Operations/Management Considerations. It is surprising to me that
such extensive work in the Standards Track didn't have any
Operations/Management (or even Security!) Considerations until the current
version. My comments below echo some of the opinions on the list, but I can't
claim that they are all inclusive. As I pointed out below, I am not looking
for a dissertation on the topic, but much more than what's there should be
included.
Thanks!
Alvaro.
Major:
1. In general, I feel uncomfortable with documents making value statements
related, for example, to how they perform against different solutions. The
purpose of this document should be to describe the technology, not to compare
against other solutions — that work (if wanted/needed) should be done in a
different document. Please remove comparisons to other technology and relative
statements. Some examples:
* Abstract: "MRT is also extremely computationally efficient…computation
is less than the LFA computation..." As was expressed on the list, maybe CPU
cycles are not that important if compared to other aspects…
* Introduction: "Other existing or proposed solutions are partial
solutions or have significant issues, as described below." It is ok to
describe other solutions, but please limit the description to the facts.
* About the table: there are obviously other columns that could have
been included, which means that the table is not complete.
* Section 4: "Modeling results comparing the alternate path lengths
obtained with MRT to other approaches are described in
[I-D.ietf-rtgwg-mrt-frr-algorithm]." I am also including the corresponding
comment in my review of that other document.
* Section 5: "is an advantage of using MRT" In this case, at least a
reference to Section 15. (Applying Policy to Select from Multiple Possible
Alternates for FRR) might be in order.
2. References to Extensions. This document being where the architecture for
MRT is defined should set the stage/define requirements for extensions that are
to be defined elsewhere, and not concern itself with the solutions themselves.
In other words, please remove references to where solutions (in the form of
extensions) are being specified. Some pointers:
* All references to I-D.ietf-ospf-mrt, I-D.ietf-isis-mrt and
I-D.ietf-mpls-ldp-mrt, except maybe the ones in Section 13. (Implementation
Status).
* There are two places where it is mentioned that the capabilities to
advertise additional loopbacks "have not been defined".
* Section 7. (MRT Island Formation) starts by talking about the "purpose
of communicating support for MRT in the IGP" which is the first time in the
document that is mentioned. While distribution with an IGP may be the obvious
mechanism, please describe the requirement.
* Another example of the same occurs in Section 8.2. (Router-specific
MRT paramaters) where it says that "additional router-specific MRT parameters
may need to be distributed via the IGP", when I think the requirement is that
these additional parameters need to be known by all routers in the MRT Island.
[Again, distribution using the IGP may be the obvious choice..]
3. Algorithm. draft-ietf-rtgwg-mrt-frr-algorithm says that it "defines
the…algorithm that is used in the default MRT profile". Please make the text
in this document consistent with that when referring to
draft-ietf-rtgwg-mrt-frr-algorithm. Some descriptions used in the text: "the
exact MRT algorithm", "the algorithm to compute MRTs", "Example algorithm"
4. Operations/Management Considerations
* Given that the MRT paths don't follow the shortest paths, or even
potentially planned backup paths in the network, I think you should include
something about the potential impact related to capacity planning, congestion,
stretch, etc.
* What about address management? Are there considerations about
assignment and management for the additional loopbacks required for IP tunnels?
* Section 15. (Applying Policy to Select from Multiple Possible
Alternates for FRR) basically says that policy can be applied "to select the
best alternate from those provided by MRT and other FRR technologies". You're
right to point out that "[I-D.ietf-rtgwg-lfa-manageability] discusses many of
the potential criteria that one might take into account when evaluating
different alternates for selection". What are the considerations that should
be taken into account when comparing between MRT and others? Are the criteria
and requirements outlined in I-D.ietf-rtgwg-lfa-manageability applicable? Even
though I-D.ietf-rtgwg-lfa-manageability is intended to be LFA-specific, should
it be a Normative reference? [Note that there's a similar comment related to
I-D.ietf-rtgwg-lfa-manageability in my review of
draft-ietf-rtgwg-mrt-frr-algorithm.]
* Applicability/Guidance for Operators
* Section 4. (Maximally Redundant Trees (MRT)) clearly explains about
the impact of not having a 2-connected network for MRT to be applicable.
Section 11.3. (MRT Alternates for Destinations Outside the MRT Island) talks
about partial implementation in an area.
* I think it would be important to consolidate some of that guidance
(there's probably more) in a single place. Note that I'm not looking for a 30
page extension (a la RFC6571), just some general guidance.
* Given that both Sections 14 and 15 were added just in the latest
version of the document, please consider taking a look at RFC5706.
* [Nit] Consider making Section 15. (Applying Policy to Select from
Multiple Possible Alternates for FRR) a sub-section of Section 14. (Operations
and Management Considerations).
5. MRT Profile Selection and Algorithm Transition:
* From Section 7.2. (Support for a specific MRT profile): "All routers
in an MRT Island MUST support the same MRT profile"…and…"A given router can
support multiple MRT profiles and participate in multiple MRT Islands.". If I
understand this correctly, routers can support multiple MRT profiles for the
same area/level, right? If so, how do the routers in the area/level agree on
which profile will be the one supported?
* Also, Section 8.1. (MRT Profile Options) says that "If a router
advertises support for multiple MRT profiles, then it MUST create the transit
forwarding topologies for each…" Are these multiple profiles inside the same
area/level? These two pieces of text don't seem to be in sync. [But I may be
missing something somewhere.]
* MRT Algorithm Transition: How is it done? In Section 8.1. (MRT
Profile Options) says that "Algorithm transitions can be managed by advertising
multiple MRT profiles", but there's no explanation of how. This comment is
related to the one above about MRT Profile Selection.
* [Minor] I may have missed this somewhere..
* The MRT MPLS MT-ID value is associated with the MRT profile, so
that (for example) the MRT-Red MPLS MT-ID for the default profile is 3997,
right? If so, how does one introduce a new profile? I'm guessing that by
registering new MT-ID values.
* What happens if the MT-ID for the Red and Blue MRTs don't
correspond to the same profile?
6. Section 17. (IANA Considerations) talks about the "MRT Profile TLV",
which is not defined anywhere in this document. I think that asking for the
registry creation is enough.
7. Section 18. (Security Considerations) Even though I don't think this
document should make explicit references to extensions, clearly there will be a
transport that needs to be secured: authentication, privacy, etc.
8. References: RFC2119 should be Normative.
Minor:
1. Section 1. (Introduction) says that: "Once traffic has been moved to one
of MRTs, it is not subject to further repair actions. Thus, the traffic will
not loop even if a worse failure (e.g. node) occurs when protection was only
available for a simpler failure (e.g. link)." I'm sure you mean that the worse
failure occurs in the original topology (not in the MRT). Please clarify.
2. Multicast protection is out of scope, right? There's a reference to
I-D.atlas-rtgwg-mrt-mc-arch in the Introduction (which is fine), but not
explicit indication of the scope. Section 8.1. (MRT Profile Options) also
talks about multicast then describing "MRT Forwarding Mechanism" ("The None
option in may be useful for multicast global protection.").
* In Section 8.1. (MRT Profile Options), is the "Area/Level Border
Behavior" specific to multicast? BTW, please avoid describing the options with
questions.
3. Section 1.1. (Importance of 100% Coverage) talks about how micro-loop
prevention is something that can be achieved with complete coverage, and
Section 12. (Network Convergence and Preparing for the Next Failure) says it is
something that needs attention after a failure, but then the document doesn't
say how MRT can be used: the use of MRT (to support Farside Tunneling) is
declared out of scope, and an "orphan" statement (no references and no
solution) about micro-loop mitigation is made ("Micro-loop mitigation
mechanisms can also work when combined with MRT.").
* Section 12.1. (Micro-forwarding loop prevention and MRTs) does say
that "Managing micro-loops is an orthogonal issue to having alternates for
local repair…", but I think you need to explain some more about how micro-loops
may not be an issue or how MRT helps.
4. Section 6.3. (Forwarding IP Unicast Traffic over MRT Paths) says that,
for IP forwarding "consistency with LDP is RECOMMENDED". Why? I'm guessing it
might be simpler to be consistent if both LDP and IP traffic are being
repaired, but what about IP-only networks?
5. Section 7.3.1. (Existing IGP exclusion mechanisms)
* "In OSPF…a metric of 2^16-1 (0xFFFF)…" RFC6987 defined a constant
called MaxLinkMetric.
* "…to prevent transit traffic from using a particular router…[RFC6987]
specifies setting all outgoing interface metrics to 0xFFFF" -- that won't
prevent traffic through the router if it's the only path, look at the R-bit in
OSPFv3; for OSPFv2, I think the latest attempt is draft-ietf-ospf-ospfv2-hbit.
* All this doesn't result in an incorrect behavior per the rules at the
end of this section.
6. Section 8.3. (Default MRT profile): s/priority/GADAG Root Selection
Priority
7. Section 10. (Inter-area Forwarding Behavior) Are there cases where it is
ok (or even desirable) to keep the traffic in MRT-Red/Blue? The circumstantial
case where independent failures occur in different areas sounds like one where
the traffic shouldn't be forwarded onto the default topology by the ABR — but
this is a case where the ABR is the entry point to a new repair. Are there
others? I'm just wondering why this Section doesn't commit (s/should/SHOULD or
even MUST) to saying that the traffic has to be taken off an MRT at an ABR.
8. Section 12.2. (MRT Recalculation for the Default MRT Profile) includes in
the MRT recalculation sequence "a configured (or advertised) period". Even
though this Section talks only about the Default MRT Profile, it seems to me
that a "recalculation timer" might be a nice things to have as part of any MRT
Profile.
* I peeked at the algorithm ID and didn't find a timer defined there
either.
Nits:
1. Please put a reference to Section 7 (?) in 1.2 when talking about MRT
Islands.
2. "Any RT is an MRT but many MRTs are not RTs." Counterintuitive since it
sounds like an MRT is the maximal version of an RT.
3. Please expand on first use: SPT, PLR, MT-ID
4. Some substitutions:
* s/it is used to described/it is used to describe
*
* s/choice of tunnel egress MAY be flexible/choice of tunnel egress is
flexible
* s/either IPv4 and IPv6/either IPv4 or IPv6
* s/Forwarding Mechanisms( MRT/Forwarding Mechanisms (MRT
* s/The key difference is whether the traffic, once out of the MRT
Island, remains in the same area/level and…/The key difference is whether the
traffic, once out of the MRT Island, remains in the same area/level or…
5. "…we will use the terms area and ABR to indicate either an OSPF area and
OSPF ABR or ISIS level and ISIS LBR", but then you use ABR/LBR and area/level
anyway. Suggestion: generalize to domain and DBR, define it in the
terminology..
6. Shouldn't there be a reference to Appendix A somewhere in Section 11?
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
