Hi Chris
Thanks for addressing my comments.
I will trim the email to just the areas that need fur
On 21/12/2015 14:47, Chris Bowers wrote:
===========
1. Introduction
SB> The text should start with the invariants and assumptions to
SB> correctly scope the claims in the introduction.
[CB] Changed the text to read:
This document describes a solution for IP/LDP fast-reroute [RFC5714].
SB> I think the assumptions are for example:
- Single link or node failure
- Can't remember if you have the means to deal with SRLG
- LF technique is in place
- method of detecting situation outside your assumptions is in place
In other words, you need to describe assumptions you are making
making about the environment in which this solution works. Whilst
RFC5714 talks around the problem, a solution needs to be
quite specific about when it breaks, (a) to alert the operator, and
(b) to make sure that the solution considers the consequences of
operating outside the specified envelope.
SB> I think you have to say where the trees are routed since only two
SB> mean you need a root, and you need to note that this is different
SB> from the underlying IGP in which there is a tree per node.
[CB] I don’t understand the distinction that you suggest noting. The MRT
computation run at each source node produces a distinct red and blue tree for
each destination node with each tree rooted at and directed towards the
destination node. The end result is similar to way that the forward SPF
computation run at each source node produces a shortest path tree for each
destination node with each tree rooted at and directed towards the destination
node.
SB> Maybe I am confused. As I recall you need to determine a single
lowpoint as the starting
point for your repair topologies. Doesn't that mean that effectively
become the root of a
pair of repair trees?
Also the low point can move under certain circumstances, and I thing
that will impact
the repair topology.
Summary Comparison of IP/LDP FRR Methods
+---------+-------------+-------------+-----------------------------+
| Method | Coverage | Alternate | Computation (in SPFs) |
| | | Looping? | |
+---------+-------------+-------------+-----------------------------+
| MRT-FRR | 100% | None | less than 3 |
| | Link/Node | | |
| | | | |
| LFA | Partial | Possible | per neighbor |
| | Link/Node | | |
| | | | |
| Remote | Partial | Possible | per neighbor (link) or |
| LFA | Link/Node | | neighbor's neighbor (node) |
| | | | |
| Not-Via | 100% | None | per link and node |
| | Link/Node | | |
| | | | |
| TI-LFA | 100% | Possible | per neighbor (link) or |
| | Link/Node | | neighbor's neighbor (node) |
+---------+-------------+-------------+-----------------------------+
SB> I really wonder how important the computational complexity is given
SB> that we are moving to an SDN world where these calculations can be
SB> offloaded?
SB>
SB> I think that it is fair to note that the other method use the
SB> existing routing protocol and calculate alternate paths using the
SB> methods of that routing protocol. Whereas with MRT you really have a
SB> new routing protocol with all of the associated operations overhead.
SB> I think this deserves consideration. The route computational world
has moved
on since this work was started.
6.1.1.1. Topology-scoped FEC encoded using a single label (Option 1A)
[RFC7307] provides a mechanism to distribute FEC-Label bindings
scoped to a given MPLS topology (represented by MPLS MT-ID). To use
multi-topology LDP to create MRT forwarding topologies, we associate
two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies,
in addition to the default shortest path forwarding topology with MT-
ID=0.
SB> Presumably you could MRT a topology other than default?
[CB] It could be done, but we focused on supporting the use case using the
default IGP topology. There is existing text in section 7 explaining this.
Deployment scenarios using multi-topology OSPF or IS-IS, or running
both ISIS and OSPF on the same routers is out of scope for this
specification.
SB> To be clear - you need 3 * the number of delivery labels in the
SB> network, and in some cases these labels identify prefix or a VPN
SB> exit point.
SB> This is a lot more labels than some of the competing schemes and so
SB> I think we really need a label table size comparison in the
SB> comparison section earlier in the document.
SB> No comment on the above?
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
