Re: WGLC for draft-rtgwg-mrt-frr-architecture

[Stewart Bryant <[e-mail]>]

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?