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

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Dec 2015 18:21:59 +0000

Resend due to problem sending to the document alias

Hi,

I am sorry that this review is late, but a number of personal matters
needed priority. Hopefully you can accept it still.

Firstly my high order bit, and I suspect I will be in the rough on this.
I am not convinced that this is the best solution that we can produce to
this problem, and I am concerned about the operational issues that
result from the non-intuitive repair paths when compared to other
methods. I am also concerned about our ability to get a solution as
complicated as this right first time in all of the corner cases.
Thus I think that rather than recommend this to the industry
as a standard, we should issue it as informational and see how it works
out at scale.

===========

  1.  Introduction

    This document gives a complete solution for IP/LDP fast-reroute
    [RFC5714].  MRT-FRR creates two alternate trees separate from the
    primary next-hop forwarding used during stable operation.  These two
    trees are maximally diverse from each other, providing link and node
    protection for 100% of paths and failures as long as the failure does
    not cut the network into multiple pieces.

SB> I am concerned that this is an overstatement.
SB> Firstly you cannot handle multiple concurrent failures in
SB> even simple pathological cases. If the network is two
SB> connected and you have both a red and blue failure
SB> that you need to traverse, you (say) commit to the red
SB> the you will fail at blue transition, even though the network is
SB> is still connected at the link level.

SB> The text should start with the invariants and assumptions to
SB> correctly scope the claims in the introduction.

SB> I think you have to say where the trees are routed since only
SB> two mean you need a root, and you need to note that this is
SB> different from the underlying IGP in which there is a tree
SB> per node.

                  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
SB> given that we are moving to an SDN world where these calculations
SB> can be 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
SB> the methods of that routing protocol. Whereas with MRT you
SB> really have a new routing protocol with all of the associated
SB> operations overhead.

============

  1.1.  Importance of 100% Coverage

    Fast-reroute is based upon the single failure assumption - that the
    time between single failures is long enough for a network to
    reconverge and start forwarding on the new shortest paths.  That does
    not imply that the network will only experience one failure or
    change.

SB> The above needs to be much earlier to qualify "complete"

===========

4.  Maximally Redundant Trees (MRT)

SB> Please remind me is there one red topology or one per failure.
SB> There is just one - correct  - so it would be useful to
SB> explain what happens in a number of instances of failure.

============

5.  Maximally Redundant Trees (MRT) and Fast-Reroute

    When there is a link or node failure affecting, but not partitioning,
SB> that should be "a single link or single node"

============

6.  Unicast Forwarding with MRT Fast-Reroute

    As mentioned before, MRT FRR needs multi-topology forwarding.
    Unfortunately, neither IP nor LDP provides extra bits for a packet to
    indicate its topology.  Once the MRTs are computed, the two sets of
    MRTs can be used as two additional forwarding topologies.  The same
    considerations apply for forwarding along the MRTs as for handling
    multiple topologies.

SB> It would be good to explain how you solve the problem mentioned
SB> in the previous para. Maybe a forward ref to a later section?

=============

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?

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
SB> VPN exit point.
SB> This is a lot more labels than some of the competing schemes
SB> and so I think we really need a label table size comparison
SB> in the comparison section earlier in the document.

=============

6.1.1.2.  Topology and FEC encoded using a two label stack (Option 1B)

    With this forwarding mechanism, a two label stack is used to encode
    the topology and the FEC of the packet.  The top label (topology-id
    label) identifies the MRT forwarding topology, while the second label
    (FEC label) identifies the FEC.  The top label would be a new FEC
    type with two values corresponding to MRT Red and Blue topologies.

    When an MRT transit router receives a packet with a topology-id
    label, the router pops the top label and uses that it to guide the
    next-hop selection in combination with the next label in the stack
    (the FEC label).  The router then swaps the FEC label, using the FEC-
    label bindings learned through normal LDP mechanisms.  The router
    then pushes the topology-id label for the next-hop.

    As with Option 1A, this forwarding mechanism also has the useful
    property that the FEC associated with the packet is maintained in the
    labels at each hop along the MRT.

    This forwarding mechanism has minimal usage of additional labels,
    memory and LDP communication.  It does increase the size of packets
    and the complexity of the required label operations and look-ups.

    This forwarding option is consistent with context-specific label
    spaces, as described in [RFC 5331].  However, the precise LDP
    behavior required to support this option for MRT has not been
    specified.

SB> So I wonder if this should be normative text given that the underlying
SB> control plane behavior is currently unknown?

SB> You should comment on the impact on forwarding moving from
SB> a one to a two label action at every hop along the repair path.
SB> This is not an issue that the competing approaches have and so
SB> should feature in the comparison section.

============

6.1.2.  MRT IP tunnels (Options 2A and 2B)

    IP tunneling can also be used as an MRT transit forwarding mechanism.
    Each router supporting this MRT transit forwarding mechanism
    announces two additional loopback addresses and their associated MRT
    color.  Those addresses are used as destination addresses for MRT-
    blue and MRT-red IP tunnels respectively.  The special loopback
    addresses allow the transit nodes to identify the traffic as being
    forwarded along either the MRT-blue or MRT-red topology to reach the
    tunnel destination.  Announcements of these two additional loopback
    addresses per router with their MRT color requires IGP extensions,
    which have not been defined.

SB> So help me understand here. How do you do this with just two
SB> loopback addresses. If I have red to a, red to b etc how
SB> do I distinguish them. Presumably you have to do this by
SB> looking inside the tunnel to find the payload. Unlike MPLS
SB> this is a much larger departure from the standard forwarding
SB> process isn't it? Again this needs to go in the comparision.

    Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the
    tunneling mechanism.

    Note that the two forwarding mechanisms using LDP Label options do
    not require additional loopbacks per router, as is required by the IP
    tunneling mechanism.  This is because LDP labels are used on a hop-
    by-hop basis to identify MRT-blue and MRT-red forwarding topologies.

6.2.  Forwarding LDP Unicast Traffic over MRT Paths

    In the previous section, we examined several options for providing
    MRT transit forwarding functionality, which is independent of the
    type of traffic being carried.  We now look at the MRT ingress
    functionality, which will depend on the type of traffic being carried
    (IP or LDP).  We start by considering LDP traffic.

    We also simplify the initial discussion by assuming that the network
    consists of a single IGP area, and that all routers in the network
    participate in MRT.  Other deployment scenarios that require MRT
    egress functionality are considered later in this document.

    In principle, it is possible to carry LDP traffic in MRT IP tunnels.
    However, for LDP traffic, it is very desirable to avoid tunneling.
    Tunneling LDP traffic to a remote node requires knowledge of remote
    FEC-label bindings so that the LDP traffic can continue to be
    forwarded properly when it leaves the tunnel.  This requires targeted
    LDP sessions which can add management complexity.

SB> I have been thinking a lot about this problem just recently
SB> whilst gardening, and you could take page from the SR playbook and use the
SB> known offset approach. I guess that is a big change, but
SB> I think we might be able to use it to avoid the longstanding distribution
SB> issue - i.e. convert the problem to offset math.

    The two MRT LDP
    Label forwarding mechanisms have the useful property that the FEC
    associated with the packet is maintained in the labels at each hop

Atlas, et al.            Expires April 17, 2016                [Page 14]

Internet-Draft        MRT Unicast FRR Architecture          October 2015

    along the MRT, as long as an MRT to the originator of the FEC is
    used.  The MRT IP tunneling mechanism does not have this useful
    property.  Therefore, this document only considers the two MRT LDP
    Label forwarding mechanisms for protecting LDP traffic with MRT fast-
    reroute.

SB> I do not understand the preceding text

  ===========

6.2.3.  Other considerations for forwarding LDP traffic using MRT LDP
         Labels

    Note that forwarding LDP traffic using MRT LDP Labels requires that
    an MRT to the originator of the FEC be used.  For example, one might
    find it desirable to have the PLR use an MRT to reach the primary
    next-next-hop for the FEC, and then continue forwarding the LDP
    packet along the shortest path tree from the primary next-next-hop.

SB> Does this mean that the packet looses it's MRT marking at this point?
SB> If so can't this result in a multi-failure repair loops?

=============

6.3.  Forwarding IP Unicast Traffic over MRT Paths

    For IP traffic, there is no currently practical alternative except
    tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red
    forwarding topology.

SB> Well isn't there a possible solution based on IPv6 options?

    The choice of tunnel egress MAY be flexible
    since any router closer to the destination than the next-hop can
    work.

SB> Again isn't  there an SRLG or other multiple failure issue with this?

==========

6.3.1.2.  Tunneling IP traffic using MRT LDP Labels (Option 1B)

    The MRT LDP Label option 1B forwarding mechanism encodes the topology
    and the FEC using a two label stack as described in Section 6.1.1.2.
    When a PLR receives an IP packet that needs to be forwarded on the
    Red MRT to a particular tunnel endpoint, the PLR pushes two labels on
    the IP packet.  The first (inner) label is the normal LDP label
    learned from the next-hop on the Red MRT, associated with a FEC
    originated by the tunnel endpoint.  The second (outer) label is the
    topology-identification label associated with the Red MRT.

    For completeness, we note here a potential optimization.  In order to
    tunnel an IP packet over an MRT to the destination of the IP packet
    (as opposed to an arbitrary tunnel endpoint), then we could just push
    a topology-identification label directly onto the packet.  An MRT
    transit router would need to pop the topology-id label, do an IP
    route lookup in the context of that topology-id , and push the
    topology-id label.

SB> What are you optimizing - certainly not the forwarding cycles.

=============

12.2.  MRT Recalculation

    When a failure event happens, traffic is put by the PLRs onto the MRT
    topologies.  After that, each router recomputes its shortest path
    tree (SPT) and moves traffic over to that.  Only after all the PLRs
    have switched to using their SPTs and traffic has drained from the
    MRT topologies should each router install the recomputed MRTs into
    the FIBs.

    At each router, therefore, the sequence is as follows:

    1.  Receive failure notification

    2.  Recompute SPT

    3.  Install new SPT

    4.  If the network was stable before the failure occured, wait a
        configured (or advertised) period for all routers to be using
        their SPTs and traffic to drain from the MRTs.

Atlas, et al.            Expires April 17, 2016                [Page 34]

Internet-Draft        MRT Unicast FRR Architecture          October 2015

    5.  Recompute MRTs

    6.  Install new MRTs.

    While the recomputed MRTs are not installed in the FIB, protection
    coverage is lowered.  Therefore, it is important to recalculate the
    MRTs and install them quickly.

SB> that is one way of doing it, anothey way is to have n MRTs running
SB> ships in the night as each failure occurs and clean up later. I think
SB> that this makes the migration timing less critical. I an not
SB> sure whether you don't need some approach like "new labels" to make
SB> this unconditionally safe.

  ===========

15.  IANA Considerations

    Please create an MRT Profile registry for the MRT Profile TLV.  The
    range is 0 to 255.  The default MRT Profile has value 0.  Values
    1-200 are by Standards Action.  Values 201-220 are for
    experimentation.  Values 221-255 are for vendor private use.

SB> I am suprised that this is not in a protocol documnet rather than the
SB> architecture since you have no data structures or encodings in here.

16.  Security Considerations

    This architecture is not currently believed to introduce new security
    concerns.

SB> I suppose you could express this in terms of the parameters being
SB> carried in the existing routing and thus you inherit their security
SB> mechanisms, and that the topology boundary is set by their boundary
SB> and thus you inherit their security and privacy characteristics.

SB> I am supprised that the draft does not say anything about the
SB> management of this new approach to FRR and the OAM that you will
SB> need to test it.

===========

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 4 Dec 2015 15:54:37 +0000

Another couple of comments on this draft.

The technique you use of selecting a single node and forming
two trees rooted at that node should really be noted up front
in the summary.

A consequence of this is that when you add a node or
when the root node fails the trees and hence the
FRR paths may change. To some extent this happens
in LFA and RLFA, although the changes will tend to
be confined to a local region, whereas with MTR I
think that the  node may move to a completely
different region. If that is the case then that has an
impact on the FRR traffic management. By way of
comparison, NV is the least impacted by this approach
and the SR approach is impacted as much as LFA, but
has the option of correcting this will a little effort.

I think that there really needs to be some text on the
matter in the architecture spec.

- Stewart

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Sun, 6 Dec 2015 04:38:59 +0000

Hi Bryant,

                Please find my observation on your comments  in line.

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

From: rtgwg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: 04 December 2015 02:22
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana
Subject: WGLC for draft-rtgwg-mrt-frr-architecture

Hi,

out at scale.

===========

 1.  Introduction

[Anil >>] I don’t think once packet moved into red path will fall back to blue path in case of red path failure.

No other FRR technologies can handle simultaneous multiple failure without loops[Loop may or may not occur which is unknown].

MRT is one of the FRR technologies which provide alternate path which tries to move away from failure point to reach the destination.

I feel we can count on the positive advantage of MRT.

SB> per node.

   |         |             |   Looping?  |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

SB> can be offloaded?

[Anil >>]  ☺ Its not wrong to claim MRT consumes much less computation compared to other FRR technologies.

Be it SDN controlled or distributed.

SB>

SB> operations overhead.

[Anil >>] As you stated in previous comment, Moving to SDN world overhead can be offloaded ☺

But I don’t feel there is much overhead compared to R-LFA or TI-LFA

============

   change.

===========

[Anil >>] Each devices will maintain three forwarding tables, one for default SPF calculated topology and other two for RED and BLUE topologies.

Default forwarding table would have backup path on red or blue forwarding table based on alternate selection.

On failure if Blue is selected as alternate path, packet will switch to Blue forwarding table.

Packet stays in blue path till it reaches the destination

If any failure is detected on blue path, packet will be dropped till SPF convergence.

============

[Anil >>] In case of MRT there is Cut-Vertex and Cut-Link, When these vertex or link fails then network is partitioned

Otherwise there exists a path to reach destination, the same would have been selected by MRT

============

   multiple topologies.

=============

   ID=0.

SB> VPN exit point.

[Anil >>] Yes MRT needs multiple tables only then packet can be guided to take disjoint path to destination.

The devices with higher forwarding entry capacity can choose to use MRT.

In case of TI-LFA label stack size is a constraint, for older devices with limited label stack capacity that would be a serious restriction.

So point is it’s a tradeoff

=============

   specified.

[Anil >>] I agree to move to comparison section.

============

[Anil >>] I agree to move to comparison section.

   tunneling mechanism.

   The two MRT LDP

   reroute.

 ===========

        Labels

=============

   forwarding topology.

   work.

==========

   topology-id label.

=============

12.2.  MRT Recalculation

   the FIBs.

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

 ===========

15.  IANA Considerations

   concerns.

SB> need to test it.

===========

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Dec 2015 11:07:09 +0000

Hi Anil

Please see inline.

Note that here we are just discussion some of the points raised.

- Stewart

On 06/12/2015 04:38, Anil Kumar S N (VRP Network BL) wrote:
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Stewart Bryant
> *Sent:* 04 December 2015 02:22
> *To:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Alvaro Retana
> *Subject:* WGLC for draft-rtgwg-mrt-frr-architecture
>
> [Anil >>] I don’t think once packet moved into red path will fall back 
> to blue path in case of red path failure.
> No other FRR technologies can handle simultaneous multiple failure 
> without loops[Loop may or may not occur which is unknown].
> MRT is one of the FRR technologies which provide alternate path which 
> tries to move away from failure point to reach the destination.
SB> I do not think that is correct.

SB> Methods that construct a repair to the next-hop (link) or 
next-next-hop (node)
SB> and refuse to repair a repair can cope with some types of multiple 
failure.
SB> For example a repair based on not-via or strict source-routing can deal
SB> with concatenated repairs. They get tricky when the second failure 
is in the
SB> repair path. Mike Shand and I looked at this but I cannot remember 
what the
SB> outcome was. However to a limited extent I think that even that might be
SB> feasible.

SB> I think that what is important here is that you specify the degree 
of completeness
SB> which is single-link, cluster of links with a single common node and 
node
SB> failure.

SB> The root cause of this constraint is the use of a pair of trees with 
a single root.
SB> This contrasts with SR and NV which have a tree rooted at every PLR and
SB> reset the repair constraint once the packet has left the repair domain.

SB> As to your point about moving away from the failure, NV certainly 
does this
SB> and with SR it depends on whether you set the repair target as the far
SB> side of the failure or Q space.

SB> The root cause of the loops in Q space is that you may not have used
SB> a sufficiently limited estimate of Q space. However if you require 
that the
SB> packet get to the next-next hop it is always safe to release it into a
SB> network that had previously converged.
> [Anil >>] JIts not wrong to claim MRT consumes much less computation 
> compared to other FRR technologies.

SB> ... but it is important to consider the importance of the 
computation constraint.
SB> In SDN you potentially have a lot more compute power available than you
SB> have in the small processor/memory systems. You also have the potential
SB> (due to massive storage) to maintain a history of common network states
SB> and thus have the configuration of the post-failure or post-repair 
states
SB> on file.

SB> You also need to consider how long it takes to do loop-free 
reconvergence
SB> to see whether the new state repair time calculation is a factor or not.
SB> For example, if you could do 50 SPF/sec it would take 10s to run one
SB> per node on a 500 node network. So then you get to the question of
SB> whether the LF strategy can be executed, and its completion notifed
SB> in 10s? If not, then the SPF computation time is not a factor.
> [Anil >>] As you stated in previous comment, Moving to SDN world 
> overhead can be offloaded J
SB> You miss my point. With MRT you have the complexity and
SB> operation characteristics of a new routing protocol to take into
SB> account. That is also the case for some of the other FRR methods
SB> but by no means all of them.

> [Anil >>] Each devices will maintain three forwarding tables, one for 
> default SPF calculated topology and other two for RED and BLUE topologies.
> Default forwarding table would have backup path on red or blue 
> forwarding table based on alternate selection.
SB> This needs to be highlighted, together with the mechanism that you 
will use
SB> to abandon the LF reconvergence.
> [Anil >>] In case of MRT there is Cut-Vertex and Cut-Link, When these 
> vertex or link fails then network is partitioned
SB> Strictly it is partitioned in the chosen MRT topology. I think it can
SB> be unpartitioned in base or the other MRT topology, it is just that
SB> they are not available to you.
> In case of TI-LFA label stack size is a constraint, for older devices 
> with limited label stack capacity that would be a serious restriction.
SB> Indeed, it is a tradeoff, but I don't think you set out the full 
tradeoff
SB> earlier in the text, and it is by no means clear that MRT is always
SB> the best trade-off.

SB> Also you need to make it clear how large the tables are.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Dec 2015 11:11:03 +0000

Resending with the correct draft alias

On 07/12/2015 11:07, Stewart Bryant wrote:
>> [Anil >>] I don’t think once packet moved into red path will fall 
>> back to blue path in case of red path failure.
> SB> which is single-link, cluster of links with a single common node 
> and node
> SB> failure.
>
> SB> The root cause of this constraint is the use of a pair of trees 
> with a single root.
>> [Anil >>] Yes MRT needs multiple tables only then packet can be 
>> guided to take disjoint path to destination.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Dec 2015 11:28:43 +0000

On 07/12/2015 11:11, Stewart Bryant wrote:
>>> MRT is one of the FRR technologies which provide alternate path 
>>> which tries to move away from failure point to reach the destination.
>> SB> and refuse to repair a repair can cope with some types of 
>> multiple failure.
>> SB> with concatenated repairs. They get tricky when the second 
>> failure is in the
>> SB> repair path. Mike Shand and I looked at this but I cannot 
>> remember what the
>> SB> I think that what is important here is that you specify the 
>> degree of completeness
>> SB> a sufficiently limited estimate of Q space. However if you 
>> require that the
>> SB> and thus have the configuration of the post-failure or 
>> post-repair states
>> SB> on file.
>>
>>> [Anil >>] Each devices will maintain three forwarding tables, one 
>>> for default SPF calculated topology and other two for RED and BLUE 
>>> topologies.
>> SB> This needs to be highlighted, together with the mechanism that 
>> you will use
>>> [Anil >>] In case of MRT there is Cut-Vertex and Cut-Link, When 
>>> these vertex or link fails then network is partitioned
>>> In case of TI-LFA label stack size is a constraint, for older 
>>> devices with limited label stack capacity that would be a serious 
>>> restriction.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 8 Dec 2015 12:07:00 +0000

Hi Stewart,

                Request you to see inline for reply.

Thanks & Regards
Anil S N

From: Stewart Bryant [mailto:[email-masked]]
Sent: 07 December 2015 19:29
To: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; Alvaro Retana
Cc: Mike Shand
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

Please see inline.

- Stewart

Thanks & Regards
Anil S N

Hi,

out at scale.

===========

 1.  Introduction

SB> Methods that construct a repair to the next-hop (link) or next-next-hop (node)
SB> and refuse to repair a repair can cope with some types of multiple failure.
SB> For example a repair based on not-via or strict source-routing can deal
SB> with concatenated repairs. They get tricky when the second failure is in the
SB> repair path. Mike Shand and I looked at this but I cannot remember what the
SB> outcome was. However to a limited extent I think that even that might be
SB> feasible.

SB> I think that what is important here is that you specify the degree of completeness
SB> which is single-link, cluster of links with a single common node and node
SB> failure.

SB> The root cause of this constraint is the use of a pair of trees with a single root.
SB> This contrasts with SR and NV which have a tree rooted at every PLR and
SB> reset the repair constraint once the packet has left the repair domain.

SB> As to your point about moving away from the failure, NV certainly does this
SB> and with SR it depends on whether you set the repair target as the far
SB> side of the failure or Q space.

SB> The root cause of the loops in Q space is that you may not have used
SB> a sufficiently limited estimate of Q space. However if you require that the
SB> packet get to the next-next hop it is always safe to release it into a
SB> network that had previously converged.

[ANIL 2 >> ]
I remember Bruno pointed out a simple topology with multiple failure can cause LOOP in SR,
I am yet to understand Not Via

Below is the topology, Where all links have a metric of 10, except AD which has 100
For the traffic from A to C, if both AC and BD links fails at the same time (and were not identified as SRLG),
there will be a loop between A and B. (and funnily (is it? ;-) ) as packets are looped,
the label stack seems to increase to “infinity” as additional P nodes (alternatively C and D) are used.

A – B
|  \  |
C – D

So multiple failure, the behavior could be undesirable. There could many unforeseen topologies
Where the extent of multiple failure and behavior might be undesired.  Please check NV against this topology.

MRT guarantees one thing for sure; if in case of multiple failure Packets would be dropped but it will not be looped.
Which is very important, looping congests line card and will be trigger for further failures. ☺

SB> per node.

   |         |             |   Looping?  |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

SB> can be offloaded?

SB> ... but it is important to consider the importance of the computation constraint.
SB> In SDN you potentially have a lot more compute power available than you
SB> have in the small processor/memory systems. You also have the potential
SB> (due to massive storage) to maintain a history of common network states
SB> and thus have the configuration of the post-failure or post-repair states
SB> on file.

SB> You also need to consider how long it takes to do loop-free reconvergence

[ANIL 2 >> ]
Let’s compare TI-LFA and MRT computation constraints, I believe MRT need less computation than TI-LFA

TI-LFA need to calculate Extended P-Space for set of destination which used each other nexthop.
Number of SPF directly depends on Number of Neighbors. If Node protection is desired then more computation is expected.

In contrary, MRT has to prepare a graph and select alternates.
If preparation of GADAG is considered as one SPF then it boils down to be very simple.

Since GADAG root is fixed, If central controller in place, if controller can collect link state information from topology
Using BGP LS or by forming IGP peer. The GADAG calculation can be delegated to controller.

Only alternate information can be downloaded by Controller. This cannot be achieved
With this ease in case where LFA calculation done for tree rooted at every PLR

My point is measurement can be of any form/measurement units, MRT has computation advantage but with implementation/understanding/algorithm complexity.

SB>

SB> operations overhead.

But I don’t feel there is much overhead compared to R-LFA or TI-LFA
SB> You miss my point. With MRT you have the complexity and
SB> operation characteristics of a new routing protocol to take into
SB> account. That is also the case for some of the other FRR methods
SB> but by no means all of them.
[ANIL 2 >> ]
In fact , MRT provides less operation complexity, If administrator know what is GADAG, he could easily figure out  what would be alternate path visually for an extent.
In simple case, if primary path matches with blue then alternate path is red. The same cannot be expected with R-LFA or TI-LFA.

It’s even difficult to send OAM packets to verify backup path in case of R-LFA and TI-LFA.
For MRT administrator can send OAM packets on RED or on BLUE path to a specific path.

MRT is quite different from traditional FRR technologies, which really has unique positive qualities.
Only thing I feel which is lacking in MRT is capability to handle multiple failure and that should not be only criteria to reject a good protocol ☺
Hope its gets due appreciation for its unique capabilities  ☺

============

   change.

===========

If any failure is detected on blue path, packet will be dropped till SPF convergence.
SB> This needs to be highlighted, together with the mechanism that you will use
SB> to abandon the LF reconvergence.
[ANIL 2 >> ] I am not an author, I wish I would; since I like this protocol ☺,
I am sure authors will update it.

============

Otherwise there exists a path to reach destination, the same would have been selected by MRT
SB> Strictly it is partitioned in the chosen MRT topology. I think it can
SB> be unpartitioned in base or the other MRT topology, it is just that
SB> they are not available to you.
[ANIL 2 >> ] I request you to elaborate this point. I didn’t understand.
As far I can say, If network has no cut vertex or cut link. MRT can provide alternate path for single failure without any issue.
Cut-vertex and Cut-Link is a issue for any FRR technologies. So it finally boils down to multiple failure which MRT doesn’t support.

============

   multiple topologies.

=============

   ID=0.

SB> VPN exit point.

So point is it’s a tradeoff
SB> Indeed, it is a tradeoff, but I don't think you set out the full tradeoff
SB> earlier in the text, and it is by no means clear that MRT is always
SB> the best trade-off.

SB> Also you need to make it clear how large the tables are.
[ANIL 2 >> ] MRT can be a best trade off in cases where , Network device has low computing powers but better forwarding capacity (access devices),
Network devices has small label stack support etc...
May be to prove the point Comparison section is needed ☺

=============

   specified.

============

   tunneling mechanism.

   The two MRT LDP

   reroute.

 ===========

        Labels

=============

   forwarding topology.

   work.

==========

   topology-id label.

=============

12.2.  MRT Recalculation

   the FIBs.

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

 ===========

15.  IANA Considerations

   concerns.

SB> need to test it.

===========

---

From: <[email-masked]>
Date: Tue, 8 Dec 2015 14:49:56 +0000

Hi Anil,

Since you have cited me, I’m probably forced to join the discussion.
As a disclaimer, as already expressed, for spring capable networks, I personally believe that TI-LFA is the best solution. So I’m not sure that you involved the right guy to support MRT ;-)

As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE…) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS))
So there may be a question whether the IETF:
a) is fine with documenting multiple/many, independent solutions,
b) is fine with many solutions but want to evaluate them to see which one is the best fit depending on the deployment case
c) whether we need to choose N solutions based on technical merits

Personally, I don’t really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that “a” had been chosen. May be “b” would make sense, assuming I’m not the one doing the job ;-) . I’m afraid “c” would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the “right” value for N, before even starting the technical evaluation)
Probably the easiest path, and in particular for the mrt draft, would be to avoid comparing solutions, and definitely avoid saying that MRT is the best solution. (And I’m not saying the draft says that, but you do in the below email) Because IMHO, comparisons are difficult, long and putting this in the mrt draft is a risk to delay it (possibly forever). But I’m also fine with discussing the comparisons. It’s really up to MRT authors.

At least I expect the choice to apply to all solutions (and not option “a” when RLFA or MRT is discussed,  and then option “c” when TI-LFA is discussed)

More inline [Bruno]

From: rtgwg [mailto:[email-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Tuesday, December 08, 2015 1:07 PM
To: Stewart Bryant; [email-masked]; [email-masked]; Alvaro Retana
Cc: Mike Shand
Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture

Hi Stewart,

Thanks & Regards
Anil S N

From: Stewart Bryant [mailto:[email-masked]]
Sent: 07 December 2015 19:29
To: Anil Kumar S N (VRP Network BL); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana
Cc: Mike Shand
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

Please see inline.

- Stewart

Thanks & Regards
Anil S N

Hi,

out at scale.

===========

 1.  Introduction

[ANIL 2 >> ]

A – B
|  \  |
C – D

[Bruno] Let’s compare the solutions with the same assumptions. If we are ready to support the cost of multiplying the size of the FIB, Segment Routing could probably advertise 2 SIDs per segments: one protected with FRR and one not protected. With this, TI-LFA can use non protected segments and hence chose to drop the packet in case of multiple unrelated failures. (rather than risking loops in some cases, to gain protections for unrelated failures in the other cases). For this TI-LFA would need to double the number of FIB entries, while I think that MRT triple it. Not to mention the choice is local and possibly on a per destination.

SB> per node.

   |         |             |   Looping?  |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

SB> can be offloaded?

[Bruno] The point is that there are multiple/many metrics to compare solutions. Picking a subset has a risk of biasing the discussion/choices.

[ANIL 2 >> ]

TI-LFA need to calculate Extended P-Space for set of destination which used each other nexthop.
Number of SPF directly depends on Number of Neighbors.

[Bruno] Yes and no. No TI-LFA does not require to compute the extended P space. But yes, you need 1 SPF per protected interface. Yes this is a cost, but this comes with a benefit of taking the best/optimal path, for each case of failure. IMHO 1 SPF per IGP interface seems a reasonable cost to me, especially before the failure.

If Node protection is desired then more computation is expected.
[Bruno] Fully agreed. But this gets topology dependent.

In contrary, MRT has to prepare a graph and select alternates.
If preparation of GADAG is considered as one SPF then it boils down to be very simple.
[Bruno] “very simple”. As a network provider, I’d rather have the solution simple to compute/understand for the human and complex to compute for the computer. Especially as human brain is not following More’s law.
Yes “simple” is difficult to measure, but I’m pretty sure that if you pick 10 regulars people, give them a network topology and ask them what would be the network behavior in case of failure, then would find TI-LFA algo easier than the MRT one.

[Bruno] My point is that this is one metric among many. And possibly not the most important.

SB>

SB> operations overhead.

[Bruno] Assuming you still need people to run and troubleshoot the network when something goes wrong, they need to understand the network. Many be your point is that at some point, these people may be softwarized in the SDN, but I’m afraid I can’t see that far in the future.

[Bruno] We could discuss the R-LFA vs MRT case, but IMHO it’s much easier to understand TI-LFA behavior than MRT or RLFA one.

SB> You miss my point. With MRT you have the complexity and
SB> operation characteristics of a new routing protocol to take into
SB> account. That is also the case for some of the other FRR methods
SB> but by no means all of them.
[ANIL 2 >> ]
In fact , MRT provides less operation complexity,
[Bruno] I disagree.
If administrator know what is GADAG, he could easily figure out  what would be alternate path visually for an extent.
[Bruno] I’m not that familiar with MRT, but that sound like ‘if the operator know the path, then he can figure out the alternate path’. Sure, but this only move the question 1 step further: how do the operator know the GADAG in a given topology?
In simple case, if primary path matches with blue then alternate path is red. The same cannot be expected with R-LFA or TI-LFA.
[Bruno] TI-LFA follows the regular Post Convergence IGP shortest path. I can’t see what would be more simpler (there is no new path/algo)

MRT is quite different from traditional FRR technologies, which really has unique positive qualities.
[Bruno] In which case it will be easy for you to demonstrate.
Only thing I feel which is lacking in MRT is capability to handle multiple failure and that should not be only criteria to reject a good protocol ☺
Hope its gets due appreciation for its unique capabilities  ☺

============

   change.

===========

============

============

   multiple topologies.

=============

   ID=0.

SB> VPN exit point.

[Bruno] For TI-LFA link protection, assuming the metric are symmetric, you can mathematically prove that the maximum number of additional labels to push is 2. For node protection this topology dependent and unbounded in theory. In practice, we have run simulation and for our networks the maximum number of labels is 4 (and if could can only push 3 labels, you only loose 0,02% of coverage). cf MPLS World Congress 2015 presentation.

So point is it’s a tradeoff
SB> Indeed, it is a tradeoff, but I don't think you set out the full tradeoff
SB> earlier in the text, and it is by no means clear that MRT is always
SB> the best trade-off.
[Bruno] +1 It’s indeed a trade-off on multiple metrics. IMHO it’s clear MRT is not always the best.

SB> Also you need to make it clear how large the tables are.
[ANIL 2 >> ] MRT can be a best trade off in cases where , Network device has low computing powers but better forwarding capacity (access devices),
Network devices has small label stack support etc...
[Bruno] access device are usually deployed in simple topologies, replicated N times. e.g. U,V, ring. In those 3 topologies, the access device has only 2 IGP links, which mean that TI-LFA link protection needs 1 SPF, typically 0 to 1 additional label to push, and typically link protection will offer de facto node protection.
May be to prove the point Comparison section is needed ☺
[Bruno] definitely needed. I’m not sure that a section will be enough. I’d rather see a research paper.

=============

   specified.

============

   tunneling mechanism.

   The two MRT LDP

   reroute.

 ===========

        Labels

=============

   forwarding topology.

   work.

==========

   topology-id label.

=============

12.2.  MRT Recalculation

   the FIBs.

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

 ===========

15.  IANA Considerations

   concerns.

SB> need to test it.

===========

_________________________________________________________________________________________________________________________

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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 9 Dec 2015 02:06:26 +0000

Hi Bruno,

                I always loved your replies (Detailed and informative) ☺

                Please see inline [Anil 3 >>]

Thanks & Regards
Anil S N

From: [email-masked] [mailto:[email-masked]]
Sent: 08 December 2015 22:50
To: Anil Kumar S N (VRP Network BL)
Cc: Mike Shand; Stewart Bryant; [email-masked]; [email-masked]; Alvaro Retana
Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture

Hi Anil,

Since you have cited me, I’m probably forced to join the discussion.
As a disclaimer, as already expressed, for spring capable networks, I personally believe that TI-LFA is the best solution. So I’m not sure that you involved the right guy to support MRT ;-)
[Anil 3 >>] Bruno, My argument was from developer point of view.

As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE…) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS))
So there may be a question whether the IETF:
a) is fine with documenting multiple/many, independent solutions,
b) is fine with many solutions but want to evaluate them to see which one is the best fit depending on the deployment case
c) whether we need to choose N solutions based on technical merits
[Anil 3 >>] I would say there should not be any restriction on number which doesn’t really matters. What matters is detailed analysis on merits and demerits of FRR technologies for each deployment scenarios.
     Then rest is left the user which one to choose.

Personally, I don’t really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that “a” had been chosen. May be “b” would make sense, assuming I’m not the one doing the job ;-) . I’m afraid “c” would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the “right” value for N, before even starting the technical evaluation)
Probably the easiest path, and in particular for the mrt draft, would be to avoid comparing solutions, and definitely avoid saying that MRT is the best solution. (And I’m not saying the draft says that, but you do in the below email) Because IMHO, comparisons are difficult, long and putting this in the mrt draft is a risk to delay it (possibly forever). But I’m also fine with discussing the comparisons. It’s really up to MRT authors.
[Anil 3 >>] I assume the reason behind comparison is,  Not to say or prove MRT is the best possible solution but while introducing a new FRR technology it make sense to see where new technology stands among current available solutions.
As I said above MRT draft can concentrate only its architecture and algorithm, the comparison with respect to deployment scenario could be new draft.

More inline [Bruno]

From: rtgwg [mailto:[email-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Tuesday, December 08, 2015 1:07 PM
To: Stewart Bryant; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana
Cc: Mike Shand
Subject: RE: WGLC for draft-rtgwg-mrt-frr-architecture

Hi Stewart,

Thanks & Regards
Anil S N

Please see inline.

- Stewart

Thanks & Regards
Anil S N

Hi,

out at scale.

===========

 1.  Introduction

[ANIL 2 >> ]

A – B
|  \  |
C – D

[Anil 3 >>]  You can do that ☺

SB> per node.

   |         |             |   Looping?  |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

SB> can be offloaded?

[Bruno] The point is that there are multiple/many metrics to compare solutions. Picking a subset has a risk of biasing the discussion/choices.
[Anil 3 >>]  OK. At least this point is accepted. ☺

[ANIL 2 >> ]

[Bruno] Yes and no. No TI-LFA does not require to compute the extended P space. But yes, you need 1 SPF per protected interface. Yes this is a cost, but this comes with a benefit of taking the best/optimal path, for each case of failure. IMHO 1 SPF per IGP interface seems a reasonable cost to me, especially before the failure.
[Anil 3 >>]  Bruno I never said it’s not reasonable, Whatever computation done before failure to provide better alternates is acceptable.

In contrary, MRT has to prepare a graph and select alternates.
If preparation of GADAG is considered as one SPF then it boils down to be very simple.
[Bruno] “very simple”. As a network provider, I’d rather have the solution simple to compute/understand for the human and complex to compute for the computer. Especially as human brain is not following More’s law.Yes “simple” is difficult to measure, but I’m pretty sure that if you pick 10 regulars people, give them a network topology and ask them what would be the network behavior in case of failure, then would find TI-LFA algo easier than the MRT one.
[Anil 3 >>]  As I can see you agree to other things except the complexity part, Yes MRT is complex to understand in the beginning since MRT algo involves multiple jargons.
Since GADAG root is fixed, If central controller in place, if controller can collect link state information from topology
Using BGP LS or by forming IGP peer. The GADAG calculation can be delegated to controller.

[Anil 3 >>]  Again you agree ☺

SB>

SB> operations overhead.

[Anil 3 >>] I agree to your point as your from Operators background. But eventually people will easily calculate GADAG graph for any topology once they gets hands on to it.

[Anil 3 >>]  reason why I co-relate R-LFA and TI-LFA is from developers point of view, The code would be generic based on context some additional/less computation is needed.

[Anil 3 >>]  Again Understanding complexity ☺

[Bruno] I’m not that familiar with MRT, but that sound like ‘if the operator know the path, then he can figure out the alternate path’. Sure, but this only move the question 1 step further: how do the operator know the GADAG in a given topology?
In simple case, if primary path matches with blue then alternate path is red. The same cannot be expected with R-LFA or TI-LFA.
[Bruno] TI-LFA follows the regular Post Convergence IGP shortest path. I can’t see what would be more simpler (there is no new path/algo)
[Anil 3 >>]  Totally agreed, Since all are familiar with SPF now they can do it. The same will happen with MRT eventually.

MRT is quite different from traditional FRR technologies, which really has unique positive qualities.
[Bruno] In which case it will be easy for you to demonstrate.
[Anil 3 >>]  Best way is to say 100% loop free , a very disjoint alternate path to destination.  ☺

============

   change.

===========

============

============

   multiple topologies.

=============

   ID=0.

SB> VPN exit point.

 [ANIL 3 >> ] You told me this, I believe it is true.

[Anil 3 >>]  Best way is to remove comparison from this draft move it in to a separate draft after enough research.

=============

   specified.

============

   tunneling mechanism.

   The two MRT LDP

   reroute.

 ===========

        Labels

=============

   forwarding topology.

   work.

==========

   topology-id label.

=============

12.2.  MRT Recalculation

   the FIBs.

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

 ===========

15.  IANA Considerations

   concerns.

SB> need to test it.

===========

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 9 Dec 2015 10:29:43 +0000

Please see more comments inline

- Stewart

On 08/12/2015 12:07, Anil Kumar S N (VRP Network BL) wrote:
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* 07 December 2015 19:29
> *To:* Anil Kumar S N (VRP Network BL); 
> [email-masked]; [email-masked]; 
> Alvaro Retana
> *Cc:* Mike Shand
> *Subject:* Re: WGLC for draft-rtgwg-mrt-frr-architecture
>
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>; Alvaro Retana
>             [Anil >>] I don’t think once packet moved into red path
>             will fall back to blue path in case of red path failure.
>
>             No other FRR technologies can handle simultaneous multiple
>             failure without loops[Loop may or may not occur which is
>             unknown].
>
>             MRT is one of the FRR technologies which provide alternate
>             path which tries to move away from failure point to reach
>             the destination.
>
>         For the traffic from A to C, if both AC and BD links fails at
>         the same time (and were not identified as SRLG),
>
>         the label stack seems to increase to “infinity” as additional
>         P nodes (alternatively C and D) are used.
>
>         A – B
>
>         |  \  |
>
>         C – D
>
>         Where the extent of multiple failure and behavior might be
>         undesired.  Please check NV against this topology.
>
>         MRT guarantees one thing for sure; if in case of multiple
>         failure Packets would be dropped but it will not be looped.
>
>         Which is very important, looping congests line card and will
>         be trigger for further failures. J
>
SB1> We addressed this problem in NV by not repairing repairs. At A the 
packet would
SB1> have gone into a tunnel from A to C via B and D with address C 
not-via AC.
SB1> B and D would of course populate their forwarding tables with the 
normal next
SB1> hop for the NV address, but instead of having a repair for the 
address, they would
SB1> have a drop for it. The result is unconditional safety of the type 
you seek with MRT.

SB1> I assume that the SR folks are trying to use the same segment 
identifiers for both
SB1> traffic engineering and repair. This is surely a mistake. By using 
a different set of identifiers
SB1> for repair, and not repairing packets that arrive with a repair SI, 
i.e. following the
SB1> the approach that we proposed in NV the SR approach would also be 
unconditionally
SB1> safe against an unexpected failure.
>         [Anil >>] JIts not wrong to claim MRT consumes much less
>         computation compared to other FRR technologies.
>
>         Let’s compare TI-LFA and MRT computation constraints, I
>         believe MRT need less computation than TI-LFA
>
>         TI-LFA need to calculate Extended P-Space for set of
>         destination which used each other nexthop.
>
>         Number of SPF directly depends on Number of Neighbors. If Node
>         protection is desired then more computation is expected.
>
>         Since GADAG root is fixed, If central controller in place, if
>         controller can collect link state information from topology
>
>         My point is measurement can be of any form/measurement units,
>         MRT has computation advantage but with
>         implementation/understanding/algorithm complexity.
>
SB1> If we are going to publish a comparison, then it needs to be 
complete, objective, and
SB1> we need to properly understand what the true importance is.

SB1> My contention, and surely the big-data and machine learning people 
will support this
SB1> is that the compute power in a data center is so large that you can 
disregard many
SB1> historic concerns about compute limitation. If the repairs are 
being computed in an
SB1> SDN controller we have massive compute power and huge storage and 
so need to be
SB1> far less concerned with the compute limitations that have 
constrained our thinking.

SB1> So in this particular case what is being done is to accept 
limitations in the repair
SB1> strategy in order to minimise computational overhead, at a time 
when we are moving
SB1> into a world where computational overhead is no longer a limiting 
factor.

SB1> BTW as I pointed out in another email, the GADAG root is not fixed 
in the event of
SB1> the failure of that node or the introduction of a new node that 
becomes the minimum.
>         [Anil >>] As you stated in previous comment, Moving to SDN
>         world overhead can be offloaded J
>
>         In fact , MRT provides less operation complexity, If
>         administrator know what is GADAG, he could easily figure out
>          what would be alternate path visually for an extent.
>
>         In simple case, if primary path matches with blue then
>         alternate path is red. The same cannot be expected with R-LFA
>         or TI-LFA.
>
SB1> The first question I have is how may admins know what a GADAG is? 
Remember up until now
SB1> all you needed to think about was what is the shortest path from 
where the packet currently
SB1> is to the destination.

SB1> I do not understand your comment about OAM. You can send OAM over 
the repair path
SB1> with any of the repair techniques. You have to send it from the 
PLR, but what is wrong with
SB1> that?

>
>         MRT is quite different from traditional FRR technologies,
>         which really has unique positive qualities.
>
>         Only thing I feel which is lacking in MRT is capability to
>         handle multiple failure and that should not be only criteria
>         to reject a good protocol J
>
>         Hope its gets due appreciation for its unique capabilities J
>
>         ============
>
>           
>
>         [Anil >>] Each devices will maintain three forwarding tables,
>         one for default SPF calculated topology and other two for RED
>         and BLUE topologies.
>
>         [ANIL 2 >> ] I am not an author, I wish I would; since I like
>         this protocol J,
>

SB1> I hope so, although so far they have been very quiet.
>         [Anil >>] In case of MRT there is Cut-Vertex and Cut-Link,
>         When these vertex or link fails then network is partitioned
>
>         As far I can say, If network has no cut vertex or cut link.
>         MRT can provide alternate path for single failure without any
>         issue.
>
>         Cut-vertex and Cut-Link is a issue for any FRR technologies.
>         So it finally boils down to multiple failure which MRT doesn’t
>         support.
>
>           
>
SB1> In the event of a single failure there is no problem, but the draft 
does not make that constraint clear.
SB1> In the event of a double serial failure (which some of the other 
methods can handle) then you
SB1> may find that there exists a path to every destination in base, but 
because one of the paths needed
SB1> was in red and the other in blue you cannot repair.

>         [Anil >>] Yes MRT needs multiple tables only then packet can
>         be guided to take disjoint path to destination.
>
>         devices with limited label stack capacity that would be a
>         serious restriction.
>
>         [ANIL 2 >> ] MRT can be a best trade off in cases where ,
>         Network device has low computing powers but better forwarding
>         capacity (access devices),
>
>         May be to prove the point Comparison section is needed J
>
SB1> If that is the constraint, then it needs to be made clear up front, 
and as I noted
SB1> earlier in the thread, the comparison needs to be expanded to be 
complete
SB1> and objective.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 9 Dec 2015 11:00:53 +0000

I largely agree with Bruno, although I have some questions about
the SR approach as well.

Please see inline.

Stewart

On 08/12/2015 14:49, [email-masked] wrote:
> As a disclaimer, as already expressed, for spring capable networks, I 
> personally believe that TI-LFA is the best solution. So I’m not sure 
> that you involved the right guy to support MRT ;-)
>
SB> A solution based on source routing is a good solution, but I have 
reservations about the particular solution given the observaion earlier 
in this thread that you cab get looping repairs. However as I noted 
there the fix is quite simple.
>
> As a general comment, we indeed have multiple FRR solutions ( e.g. 
> TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop 
> link protection, end to end RSVP-TE FRR (multiple flavors and new 
> additional extensions discussed in MPLS WG), some mid point to some 
> other mid points RSVP-TE…) plus discussed in multiple WG (RTGWG and 
> MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING 
> (although TI-FRR could possibly also be discussed in RTGWG rather than 
> MPLS))
>
> b) is fine with many solutions but want to evaluate them to see which 
> one is the best fit depending on the deployment case
>
> Personally, I don’t really have a strong preference, but they seem 
> ranked from faster/easier to longer/harder. So far I assumed that “a” 
> had been chosen. May be “b” would make sense, assuming I’m not the one 
> doing the job ;-) . I’m afraid “c” would burn many times, for limited 
> benefits. (I can already foresee some lengthy discussions just to pick 
> the “right” value for N, before even starting the technical evaluation)
>
> Probably the easiest path, and in particular for the mrt draft, would 
> be to avoid comparing solutions, and definitely avoid saying that MRT 
> is the best solution. (And I’m not saying the draft says that, but you 
> do in the below email) Because IMHO, comparisons are difficult, long 
> and putting this in the mrt draft is a risk to delay it (possibly 
> forever). But I’m also fine with discussing the comparisons. It’s 
> really up to MRT authors.
>
SB> My interpretation of the text in the draft is that it is making the 
claim that it is the best solution.
SB> My assertion is that this is not the case, and at the moment I hold 
that position for all of the
SB> candidate solutions, since all of them have limitations.
SB>
SB> I would propose (b) by only publishing the designs as informational 
and then anointing one or more
SB> as standard when we have significant deployment experience.

> At least I expect the choice to apply to all solutions (and not option 
> “a” when RLFA or MRT is discussed,and then option “c” when TI-LFA is 
> discussed)
>
> More inline [Bruno]
>
> *From**:*rtgwg [mailto:[email-masked]] *On Behalf Of *Anil 
> Kumar S N (VRP Network BL)
> *Sent:* Tuesday, December 08, 2015 1:07 PM
> *To:* Stewart Bryant; 
> *Subject:* RE: WGLC for draft-rtgwg-mrt-frr-architecture
>
> Hi Stewart,
>
> [email-masked] 
> <mailto:[email-masked]>; 
>         [Bruno] Let’s compare the solutions with the same assumptions.
>         If we are ready to support the cost of multiplying the size of
>         the FIB, Segment Routing could probably advertise 2 SIDs per
>         segments: one protected with FRR and one not protected. With
>         this, TI-LFA can use non protected segments and hence chose to
>         drop the packet in case of multiple unrelated failures.
>         (rather than risking loops in some cases, to gain protections
>         for unrelated failures in the other cases). For this TI-LFA
>         would need to double the number of FIB entries, while I think
>         that MRT triple it. Not to mention the choice is local and
>         possibly on a per destination.
>
SB> That is the right approach, but it is surely not that onerous. You 
only double the
SB> nodal segments, not the whole table. Same for the number of 
interfaces. I am
SB> not sure what the latest numbers are, but when I was studying this, 
the largest
SB> network we had was 500 nodes and k was about 8 to 10, so that would be
SB> just over 500 additional labels which seems pretty small.

>            |         |             |   Looping? 
>         |                             |
>            |         |  Link/Node  |            
>         |                             |
>            |         |             |            
>         |                             |
>            |         |  Link/Node  |            
>         |                             |
>            |         |             |            
>         |                             |
>            |         |             |            
>         |                             |
>            |         |  Link/Node  |             | 
>                                    |
>            |         |             |            
>         |                             |
>         [Bruno] The point is that there are multiple/many metrics to
>         compare solutions. Picking a subset has a risk of biasing the
>         discussion/choices.
>

SB> Again, exactly my point.
>         [Bruno] Yes and no. No TI-LFA does not require to compute the
>         extended P space. But yes, you need 1 SPF per protected
>         interface. Yes this is a cost, but this comes with a benefit
>         of taking the best/optimal path, for each case of failure.
>         IMHO 1 SPF per IGP interface seems a reasonable cost to me,
>         especially before the failure.
>

SB> Exactly, and to put that in perspective that is something like 
k(=10) * 20ms (SPF time).
SB> not a big deal.
>         [Bruno] “very simple”. As a network provider, I’d rather have
>         the solution simple to compute/understand for the human and
>         complex to compute for the computer. Especially as human brain
>         is not following More’s law.
>
>         Yes “simple” is difficult to measure, but I’m pretty sure that
>         if you pick 10 regulars people, give them a network topology
>         and ask them what would be the network behavior in case of
>         failure, then would find TI-LFA algo easier than the MRT one.
>
SB> They would find any SPF solution easier to follow, since they are 
familiar with the
SB> concept of adding up the metrics from the point where the packet is.
SB>
SB> With MRT they have to figure this out based on the global topology, 
not the local fragment.
>         [Bruno] Assuming you still need people to run and troubleshoot
>         the network when something goes wrong, they need to understand
>         the
>
>         network. Many be your point is that at some point, these
>         people may be softwarized in the SDN, but I’m afraid I can’t
>         see that far in the future.
>
>         [Bruno] We could discuss the R-LFA vs MRT case, but IMHO it’s
>         much easier to understand TI-LFA behavior than MRT or RLFA one.
>
>         If administrator know what is GADAG, he could easily figure
>         out  what would be alternate path visually for an extent.
>
>         [Bruno] I’m not that familiar with MRT, but that sound like
>         ‘if the operator know the path, then he can figure out the
>         alternate path’. Sure, but this only move the question 1 step
>         further: how do the operator know the GADAG in a given topology?
>
>         [Bruno] TI-LFA follows the regular Post Convergence IGP
>         shortest path. I can’t see what would be more simpler (there
>         is no new path/algo)
>

SB> I do have some concerns about this, but we should take those to a 
different thread.
SB> Specifically the paths are only aligned from the PLR, and not from 
the point of entry
SB> into the network, and thus I do not understand what advantage this 
constraint has
SB> in practice.
>         [Bruno] For TI-LFA link protection, assuming the metric are
>         symmetric, you can mathematically prove that the maximum
>         number of additional labels to push is 2. For node protection
>         this topology dependent and unbounded in theory. In practice,
>         we have run simulation and for our networks the maximum number
>         of labels is 4 (and if could can only push 3 labels, you only
>         loose 0,02% of coverage). cfMPLS World Congress 2015 presentation.
>
SB> So - at this is really a question for the WG as a whole, is the 
symmetry constraint in or out?
SB> I think the MRT team are asserting that the symmetry constraint is 
not being applied, and
SB> indeed this is a basis for some of their own assertions.
SB>
SB> A symmetry constraint would be a major and useful constraint in 
simplifying the solution design.
>         Network devices hassmall label stack support etc...
>
>         [Bruno] access device are usually deployed in simple
>         topologies, replicated N times. e.g. U,V, ring. In those 3
>         topologies, the access device has only 2 IGP links, which mean
>         that TI-LFA link protection needs 1 SPF, typically 0 to 1
>         additional label to push, and typically link protection will
>         offer de facto node protection.
>

SB> Well in the IETF context it needs a draft -> RFC.
SB> However it would be acceptable in my view to develop and deploy the 
various solutions,
SB> do the analysis, and then make a statement about which the IETF 
endorse through
SB> the standards process.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 9 Dec 2015 11:10:59 +0000

On 09/12/2015 02:06, Anil Kumar S N (VRP Network BL) wrote:
>
> Hi Bruno,
>
> I always loved your replies (Detailed and informative) J
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* 08 December 2015 22:50
> *To:* Anil Kumar S N (VRP Network BL)
> *Cc:* Mike Shand; Stewart Bryant; 
> [Anil 3 >>] I would say there should not be any restriction on number 
> which doesn’t really matters. What matters is detailed analysis on 
> merits and demerits of FRR technologies for each deployment scenarios.
>

SB> We have consensus on this point, at least amongst the three of us, 
which leads to
SB> the question of whether we are ready to move beyond experimental or 
informational
SB> until the market shows us the direction.
> [Anil 3 >>] I assume the reason behind comparison is,  Not to say or 
> prove MRT is the best possible solution but while introducing a new 
> FRR technology it make sense to see where new technology stands among 
> current available solutions.
>
> As I said above MRT draft can concentrate only its architecture and 
> algorithm, the comparison with respect to deployment scenario could be 
> new draft.
>
SB> I agree, that is the right approach, since a detailed comparison 
will dominate the RFC.

SB> This also makes me wonder whether we shouldn't take separate the 
algorithm from the MRT
SB> context in the algorithm draft so as not to hold the IEEE up?
> “a” when RLFA or MRT is discussed,  and then option “c” when TI-LFA is 
> discussed)
>
> More inline [Bruno]
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Anil Kumar 
> S N (VRP Network BL)
>         [Anil 3 >>]  You can do that J
>
>         [Anil 3 >>]  OK. At least this point is accepted. J
>
>
>         [Anil 3 >>]  Bruno I never said it’s not reasonable, Whatever
>         computation done before failure to provide better alternates
>         is acceptable.
>
>         is not following More’s law.Yes “simple” is difficult to
>         measure, but I’m pretty sure that if you pick 10 regulars
>         people, give them a network topology and ask them what would
>         be the network behavior in case of failure, then would find
>         TI-LFA algo easier than the MRT one.
>
>         [Anil 3 >>]  As I can see you agree to other things except the
>         complexity part, Yes MRT is complex to understand in the
>         beginning since MRT algo involves multiple jargons.
>
>         [Anil 3 >>]  Again you agree J
>
>         SB>
>
>         the network. Many be your point is that at some point, these
>         [Anil 3 >>] I agree to your point as your from Operators
>         background. But eventually people will easily calculate GADAG
>         graph for any topology once they gets hands on to it.
>
>         [Anil 3 >>]  reason why I co-relate R-LFA and TI-LFA is from
>         developers point of view, The code would be generic based on
>         context some additional/less computation is needed.
>
>         [Anil 3 >>]  Again Understanding complexity J
>
>         [Anil 3 >>]  Totally agreed, Since all are familiar with SPF
>         now they can do it. The same will happen with MRT eventually.
>
>         [Anil 3 >>]  Best way is to say 100% loop free , a very
>         disjoint alternate path to destination. J
>
SB> To get 100% loop free and have optimum paths post convergence, you 
need to impose
SB> a strategy of the type proposed in the LF framework RFC, unless we 
missed one in that
SB> RFC.

>         loose 0,02% of coverage). cf MPLS World Congress 2015
>         presentation.
>
>         [Anil 3 >>]  Best way is to remove comparison from this draft
>         move it in to a separate draft after enough research.
>
>         =============
>
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> As emails may be altered, France Telecom - Orange shall not be liable 
> if this message was modified, changed or falsified.
> Thank you.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 9 Dec 2015 16:52:13 +0000

On 12/8/15, 9:49 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

[Speaking as an individual.]

[This is a little bit off the topic of draft-rtgwg-mrt-frr-architecture.  But worth discussing.]

As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE...) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS))

Even if we reduce the scope of the question from the IETF to the Routing Area or even a specific WG, the answer is probably going to be in line with your thoughts:

 Personally, I don't really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that "a" had been chosen. May be "b" would make sense, assuming I'm not the one doing the job ;-) . I'm afraid "c" would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the "right" value for N, before even starting the technical evaluation)

I agree.  "c" opens a can of worms that no one wants.

My personal opinion is that there's nothing wrong with "a" [*].

While you didn't explicitly say so, "b" could be interpreted as related to the Status (Standard, Experimental, Informational) of the work.  It may be interesting to evaluate which solution is the best fit [**], but then again, I don't see anything wrong with "a".  Even if a document is published as a Proposed Standard, it should never make it to an Internet Standard is people don't use it.

Having said that, I also think that (given that there's nothing wrong with "a"), a WG may decide on a specific Status based on the fit of the technology to the deployment case(s), the existence (or not) of other solutions, etc.    Just a personal opinion..

Alvaro.

[*] Unless a WG is explicitly chartered to provide a single solution, of course.
[**] That is probably another can of worms. :-(

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Dec 2015 13:03:08 +0000

Alvaro

My experience of the IETF is that it tries quite hard to get to a single
solution per problem domain on the standards track. Now maybe the
IESG position on this has changed but the expectation is that normally
there would only be a single ST RFC. Also ST normally expresses a
view that the solution is the best we currently have and I do not
believe there is consensus in the WG for that position.

Are you making a definitive statement that publishing this as ST
will not preclude the publication of other competing solutions
at the same level?

- Stewart

On 09/12/2015 16:52, Alvaro Retana (aretana) wrote:
> On 12/8/15, 9:49 AM, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> [This is a little bit off the topic of 
> draft-rtgwg-mrt-frr-architecture.  But worth discussing.]
>
>     As a general comment, we indeed have multiple FRR solutions( e.g.
>     TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1
>     hop link protection, end to end RSVP-TE FRR (multiple flavors and
>     new additional extensions discussed in MPLS WG), somemid pointto
>     some other mid points RSVP-TE…) plus discussed in multiple WG
>     (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG
>     rather than SPRING (although TI-FRR could possibly also be
>     discussed in RTGWG rather than MPLS))
>
>     a)isfine with documenting multiple/many, independent solutions,
>
>     b)isfine with many solutions but want to evaluate them to see
>     which one is the best fit depending on the deployment case
>
>     c)whetherwe need to choose N solutions based on technical merits
>
>
> Even if we reduce the scope of the question from the IETF to the 
> Routing Area or even a specific WG, the answer is probably going to be 
> in line with your thoughts:
>
>     ranked from faster/easier to longer/harder. So far I assumed that
>     “a” had been chosen. May be “b” would make sense, assuming I’m not
>     the one doing the job ;-) . I’m afraid “c” would burn many times,
>     for limited benefits. (I can already foresee some lengthy
>     discussions just to pick the “right” value for N, before even
>     starting the technical evaluation)
>
>
> While you didn't explicitly say so, "b" could be interpreted as 
> related to the Status (Standard, Experimental, Informational) of the 
> work.  It may be interesting to evaluate which solution is the best 
> fit [**], but then again, I don't see anything wrong with "a".  Even 
> if a document is published as a Proposed Standard, it should never 
> make it to an Internet Standard is people don't use it.
>
> Having said that, I also think that (given that there's nothing wrong 
> with "a"), a WG may decide on a specific Status based on the fit of 
> the technology to the deployment case(s), the existence (or not) of 
> other solutions, etc.    Just a personal opinion..
>
> Alvaro.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Thu, 10 Dec 2015 13:32:26 +0000

Hi Stewart,

Please see inline [Bruno2]

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, December 09, 2015 12:01 PM
To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL)
Cc: Mike Shand; [email-masked]; [email-masked]; Alvaro Retana
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

Please see inline.

Stewart

On 08/12/2015 14:49, [email-masked]<mailto:[email-masked]> wrote:
Hi Anil,

Since you have cited me, I’m probably forced to join the discussion.
As a disclaimer, as already expressed, for spring capable networks, I personally believe that TI-LFA is the best solution. So I’m not sure that you involved the right guy to support MRT ;-)
SB> A solution based on source routing is a good solution, but I have reservations about the particular solution given the observaion earlier in this thread that you cab get looping repairs. However as I noted there the fix is quite simple.
[Bruno2] ack.

Personally, I don’t really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that “a” had been chosen. May be “b” would make sense, assuming I’m not the one doing the job ;-) . I’m afraid “c” would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the “right” value for N, before even starting the technical evaluation)
Probably the easiest path, and in particular for the mrt draft, would be to avoid comparing solutions, and definitely avoid saying that MRT is the best solution. (And I’m not saying the draft says that, but you do in the below email) Because IMHO, comparisons are difficult, long and putting this in the mrt draft is a risk to delay it (possibly forever). But I’m also fine with discussing the comparisons. It’s really up to MRT authors.
SB> My interpretation of the text in the draft is that it is making the claim that it is the best solution.
SB> My assertion is that this is not the case, and at the moment I hold that position for all of the
SB> candidate solutions, since all of them have limitations.
SB>
SB> I would propose (b) by only publishing the designs as informational and then anointing one or more
SB> as standard when we have significant deployment experience.

[Bruno2] “b” is fine for me. Regarding publishing as informational the next FRR solutions, in the absence of technical justification (i.e. before evaluation) I feel that this is arbitrarily changing the rule, as LFA, RLFA and draft-ietf-rtgwg-rlfa-node-protection are STD track. And even for/after evaluation, this is a risk of biasing the evaluation or making it longer and harder to agree on. Taking into account deployment experience sounds like a good idea to me.

More inline [Bruno]

Hi Stewart,

Thanks & Regards
Anil S N

Please see inline.

- Stewart

Thanks & Regards
Anil S N

Hi,

out at scale.

===========

 1.  Introduction

[ANIL 2 >> ]

A – B
|  \  |
C – D

[Bruno] Let’s compare the solutions with the same assumptions. If we are ready to support the cost of multiplying the size of the FIB, Segment Routing could probably advertise 2 SIDs per segments: one protected with FRR and one not protected. With this, TI-LFA can use non protected segments and hence chose to drop the packet in case of multiple unrelated failures. (rather than risking loops in some cases, to gain protections for unrelated failures in the other cases). For this TI-LFA would need to double the number of FIB entries, while I think that MRT triple it. Not to mention the choice is local and possibly on a per destination.
SB> That is the right approach, but it is surely not that onerous. You only double the
SB> nodal segments, not the whole table. Same for the number of interfaces. I am
SB> not sure what the latest numbers are, but when I was studying this, the largest
SB> network we had was 500 nodes and k was about 8 to 10, so that would be
SB> just over 500 additional labels which seems pretty small.
[Bruno2] Agree. Plus the additional operational cost to allocate and configure an additional SID on all nodes. Probably easier when SR is originally provisioned. compared to doing the work twice. However, people may only have the need and hence the incentive when they won’t to deploy SR FRR, which is possibly after SR deployment.
FYI, as of today
- SR defines a non protected adjacency segments but not (yet) a non protected prefix SID.
- SR FRR use case discuss a related issue (non protected tunnels) https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-02#section-2
- TI LFA does not (yet) discuss this point (IIRC)

SB> per node.

   |         |             |   Looping?  |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |         |             |             |                             |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

SB> can be offloaded?

[ANIL 2 >> ]

SB> Exactly, and to put that in perspective that is something like k(=10) * 20ms (SPF time).
SB> not a big deal.

In contrary, MRT has to prepare a graph and select alternates.
If preparation of GADAG is considered as one SPF then it boils down to be very simple.
[Bruno] “very simple”. As a network provider, I’d rather have the solution simple to compute/understand for the human and complex to compute for the computer. Especially as human brain is not following More’s law.
Yes “simple” is difficult to measure, but I’m pretty sure that if you pick 10 regulars people, give them a network topology and ask them what would be the network behavior in case of failure, then would find TI-LFA algo easier than the MRT one.
SB> They would find any SPF solution easier to follow, since they are familiar with the
SB> concept of adding up the metrics from the point where the packet is.
SB>
SB> With MRT they have to figure this out based on the global topology, not the local fragment.

SB>

SB> operations overhead.

[Bruno] Assuming you still need people to run and troubleshoot the network when something goes wrong, they need to understand the

network. Many be your point is that at some point, these people may be softwarized in the SDN, but I’m afraid I can’t see that far in the future.

SB> I do have some concerns about this, but we should take those to a different thread.
SB> Specifically the paths are only aligned from the PLR, and not from the point of entry
SB> into the network,
[Bruno2] Sure. There is nothing a local reaction can do about this.
SB>  and thus I do not understand what advantage this constraint has
SB> in practice.
[Bruno2] Even if it’s not end to end (and we could discuss what end to end means), it’s still better to minimize the cost in within the perimeter. Whether the cost is delay, money, bandwidth, or network engineering preference. Besides, SP routing design/preference rules are typically encoded in the IGP metrics, so that regular IGP routing take them into account. e.g. Some VPN SP have a design rule to not use PE as P (LSR) routers. This rule is reflected in the IGP metric, hence a FRR solution minimizing the IGP metric will follow that rule

============

   change.

===========

============

============

   multiple topologies.

=============

   ID=0.

SB> VPN exit point.

 <

/o:p>

SB> So - at this is really a question for the WG as a whole, is the symmetry constraint in or out?
SB> I think the MRT team are asserting that the symmetry constraint is not being applied, and
SB> indeed this is a basis for some of their own assertions.
SB>
SB> A symmetry constraint would be a major and useful constraint in simplifying the solution design.

SB> Well in the IETF context it needs a draft -> RFC.
SB> However it would be acceptable in my view to develop and deploy the various solutions,
SB> do the analysis, and then make a statement about which the IETF endorse through
SB> the standards process.
[Bruno2] Looks reasonable to me.

=============

   specified.

============

   tunneling mechanism.

   The two MRT LDP

   reroute.

 ===========

        Labels

=============

   forwarding topology.

   work.

==========

   topology-id label.

=============

12.2.  MRT Recalculation

   the FIBs.

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

 ===========

15.  IANA Considerations

   concerns.

SB> need to test it.

===========

Thank you.

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.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 10 Dec 2015 18:03:28 +0000

On 12/10/15, 8:03 AM, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>> wrote:

[Still speaking as an individual.]

Stewart:

Hi!

As I wrote below, my statements were made as an individual.

As I also wrote below, "(given that there's nothing wrong with "a"), a WG may decide on a specific Status based on the fit of the technology to the deployment case(s), the existence (or not) of other solutions, etc.".

To specifically answer your question.  My statement is as definitive as my personal opinion is right now.  I don't see anything in the current rtgwg charter that precludes the publication of other solutions into the Standards Track - with the caveat of course that the WG should follow the normal process and make the decision itself.

Alvaro.

- Stewart

Alvaro.

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Chris Bowers <[email-masked]>
Date: Mon, 21 Dec 2015 14:47:17 +0000

Steward,

I don't agree with the initial statement that the technique forms two trees rooted at a single node.  The designation of the GADAG root plays an important role in computing the red and blue MRT trees.  However,  red and blue MRT trees are computed using forward SPFs rooted at each source, which follow the directed links on the GADAG and do not propagate past the GADAG root.  The net result of these computations can be viewed as producing red and blue MRT trees rooted at each destination.  In any case, these trees are not rooted at the GADAG root.  

Anil pointed out that the pseudo-code in draft-ietf-rtgwg-mrt-frr-algorithm didn't always make a clear distinction between the root of the forward SPF computation and the GADAG root, so we tried to clarify that in this set of changes.

https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/ada619050ec9d773b7919a1c622f068d5a5a5e88

Are there places in the architecture document where similar clarifications should be made?

Chris

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, December 04, 2015 9:55 AM
To: [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

The technique you use of selecting a single node and forming two trees rooted at that node should really be noted up front in the summary.

A consequence of this is that when you add a node or when the root node fails the trees and hence the FRR paths may change. To some extent this happens in LFA and RLFA, although the changes will tend to be confined to a local region, whereas with MTR I think that the  node may move to a completely different region. If that is the case then that has an impact on the FRR traffic management. By way of comparison, NV is the least impacted by this approach and the SR approach is impacted as much as LFA, but has the option of correcting this will a little effort.

I think that there really needs to be some text on the matter in the architecture spec.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 23 Dec 2015 12:33:15 +0000

> I don't agree with the initial statement that the technique forms two trees rooted at a single node.  The designation of the GADAG root plays an important role in computing the red and blue MRT tre…
Ah, OK.

However the GADAG root can move, does that not have an impact on the 
repair topology? It sounds from the above as if it might since you say 
you say that the root sets a propagation limit.

- Stewart

---

From: Chris Bowers <[email-masked]>
Date: Wed, 23 Dec 2015 17:59:41 +0000

Stewart,

I added the following text to the algorithm draft to address this point.

Chris

https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/4ae44182092f13b769834e73150837824c5b0047

   It is expected that an operator will designate a set of routers as
   good choices for selection as GADAG root by setting the GADAG Root
   Selection Priority for that set of routers to lower (more preferred)
   numerical values.

   If the router currently selected as GADAG root becomes unreachable in
   the IGP topology, then a new GADAG root will be selected.  Changing
   the GADAG root can change the overall structure of the GADAG as well
   the paths of the red and blue MRT trees built using that GADAG.  In
   order to minimize change in the associated red and blue MRT
   forwarding entries that can result from changing the GADAG root, it
   is RECOMMENDED that operators prioritize for selection as GADAG root
   those routers that are expected to consistently remain part of the
   IGP topology.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, December 23, 2015 6:33 AM
To: Chris Bowers <[email-masked]>; [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

Ah, OK.

However the GADAG root can move, does that not have an impact on the repair topology? It sounds from the above as if it might since you say you say that the root sets a propagation limit.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 23 Dec 2015 18:29:57 +0000

Hi Chris

That looks good.

Stewart