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

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

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: Rob Shakir <[email-masked]>
Date: Mon, 14 Dec 2015 10:31:34 -0700

Hi Stewart, Authors,
 
On 3 December 2015 at 11:03:27, Stewart Bryant ([email-masked](mailto:[email-masked])) wrote:
> 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.  

Whilst I’m not sure that I can comment whether this is the ‘best’ solution - I have (previously) spent some time thinking about the problem of disjointness and the applicability of this technique to some of the operational problems that I have had to deal with.

I have a couple of operationally-focused considerations that I think the operator of any network that is thinking of deploying MRTs would need to be thinking about. Primarily, we must say that we are happy with having one set of disjoint topologies (the MRT red/blue), which is utilised during the failure case. This might mean that node A and node B, which are topologically very close to one another might forward via a more indirect path based on the fact that the ‘red’ or ‘blue’ single tree that was selected is less optimal than a local set of disjoint paths that could be found. This means that we need to be able to say that the traffic that we are carrying via this network is also tolerant of that sub-optimality between those two nodes. In a world of less networks, and more variant traffic being carried on them, I am not sure that we can.

The second concern that I have with this approach is around operational influence of path selection. I have not re-reviewed the architecture again in great detail before sending this e-mail, so would apologise in advance if there are nuances that I did not understand. We have seen from LFA that whilst there may be N ways for traffic to get from A to B during a repair, from an operational perspective, not all paths are created equal (and hence we have the LFA manageability work). For example, paths that conform to ‘normal’ traffic routing within the network are generally preferred for manageability and capacity planning reasons. I would agree that we should leave this draft as informational, until such time as we have demonstrated, in live networks,  whether these operational challenges can be met by the MRT approach.

The reason for my reticence is that in the networks that I have operated that have tried to have single network-wide distribution trees, or single sets of repair paths, we have always ended up splitting things out (even when from a service perspective, they may have looked the same) to meet the myriad of business and operational concerns that we need to meet. To this end, I would be encouraging any operator that is thinking of using MRT for disjointness, or for repair, to consider what happens when they end up needing different treatment per-application, per-customer, or per-traffic class. At this point, one would want to compare the complexity of whether MRTs could be extended to these applications (that is to say, whether a set of (network-wide) “global” repair paths will be suitable), or whether they really would be better setting the foundation of having the ability to deploy a local repair paths, and building their operational processes around that.

At the end of the day, in my opinion, it is the operational process around these technologies that is the most complex thing to change, and I’m concerned that if I recommended building this process around MRT, I would be establishing new processes around something that offered more ability to do locally- rather than globally-optimal repair paths in the future.

Just my $0.02. There’s some interesting work here, but I share some of Stewart’s concerns.

Kind regards,
r.

---

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

Stewart,

Thanks for your feedback.  Please see inline [CB] for responses.

The diff of the new version can be found at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-08

Chris

From: rtgwg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, December 03, 2015 12:03 PM
To: [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Subject: WGLC for draft-rtgwg-mrt-frr-architecture

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

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

[CB] Changed the text to read:
This document describes a solution for IP/LDP fast-reroute    [RFC5714].  

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

[CB]  I don’t understand the distinction that you suggest noting.  The MRT computation run at each source node produces a distinct red and blue tree for each destination node with each tree rooted at and directed towards the destination node.  The end result is similar to way that the forward SPF computation run at each source node produces a shortest path tree for each destination node with each tree rooted at and directed towards the destination node.  

SB> I really wonder how important the computational complexity is given 
SB> that we are moving to an SDN world where these calculations can be 
SB> offloaded?
SB> 
SB> I think that it is fair to note that the other method use the 
SB> existing routing protocol and calculate alternate paths using the 
SB> methods of that routing protocol. Whereas with MRT you really have a 
SB> new routing protocol with all of the associated operations overhead.

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

[CB] I removed the unqualified occurrences of "complete" and left those which refer to "complete coverage".  

===========

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 explain what 
SB> happens in a number of instances of failure.

[CB] There is one red tree per destination.

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

[CB] corrected.

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

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

[CB] I decided to delete this paragraph.  It seems like the info in it is covered more clearly elsewhere.

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

[CB] It could be done, but we focused on supporting the use case using the default IGP topology.  There is existing text in section 7 explaining this.
  
 Deployment scenarios using multi-topology OSPF or IS-IS, or running
   both ISIS and OSPF on the same routers is out of scope for this
   specification.

SB> To be clear - you need 3 * the number of delivery labels in the 
SB> network, and in some cases these labels identify prefix or a VPN 
SB> exit point.
SB> This is a lot more labels than some of the competing schemes and so 
SB> I think we really need a label table size comparison in the 
SB> comparison section earlier in the document.

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

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

SB> You should comment on the impact on forwarding moving from a one to 
SB> 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.

[CB]The second to last paragraph above mentions the complexity of the required label operations and look-ups.

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

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 do I 
SB> distinguish them. Presumably you have to do this by looking inside 
SB> the tunnel to find the payload. Unlike MPLS this is a much larger 
SB> departure from the standard forwarding process isn't it? Again this 
SB> needs to go in the comparision.

[CB]  I added the following text to the draft to clarify.

   For example, an MRT ingress router can cause a
   packet to be tunneled along the MRT-red path to router X by
   encapsulating the packet using the MRT-red loopback address
   advertised by router X.  Upon receiving the packet, router X would
   remove the encapsulation header and forward the packet based on the
   original destination address.
   
 ----------------------------

SB> I have been thinking a lot about this problem just recently whilst 
SB> 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 I think we 
SB> might be able to use it to avoid the longstanding distribution issue
SB> - i.e. convert the problem to offset math.

   The two MRT LDP

[CB]  I changed the text to:

  As described below, the two MRT forwarding mechanisms that
  use LDP labels do not require targeted LDP sessions.

 ===========

[CB]  I rewrote the paragraph as below to make it clear that main usage is to stay on the MRT all the way to the destination.

Note that forwarding LDP traffic using MRT LDP Labels can be done without the use of targeted LDP sessions when an MRT path to the destination FEC is used. The alternates selected in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> use the MRT path to the destination FEC, so targeted LDP sessions are not needed. If instead one found 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, this would require tunneling to the primary next-next-hop and a targeted LDP session for the PLR to learn the FEC-label binding for primary next-next-hop to correctly forward the packet.

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

[CB]  Agreed.  I have modified the text in the draft to read:

   For IPv4 traffic, there is no currently practical alternative except
   tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red
   forwarding topology.  For IPv6 traffic, in principle one could define
   bits in the IPv6 options header to indicate the MRT-Blue or MRT-Red
   forwarding topology.  However, in this document, we have chosen not
   to define a solution that would work for IPv6 traffic but not for
   IPv4 traffic.---------------------

[CB]  I don’t think there is a special consideration with respect to multiple failures for taking an MRT path to a router that is not the destination, except that the process of analyzing the end-to-end path to identify shared risks would involve to parts, the MRT path to the intermediate node and the shortest path from the intermediate node to destination.  

==========

[CB] clarified with the text below.

   For completeness, we note here a potential variation that uses a
   single label as opposed to two labels.

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

12.2.  MRT Recalculation

   2.  Recompute SPT

   3.  Install new SPT

   5.  Recompute MRTs

   6.  Install new MRTs.

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 
SB> think 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.

[CB]  Agreed.  I added the following text to this section to clarify that this is the procedure being specified for the Default MRT profile, but that other approaches are possible.  I also made some minor changes in the description of profiles in general and the Default Profile specifically to clarify this.  

-------
   This section describes how the MRT recalculation SHOULD be performed
   for the Default MRT Profile.  This is intended to support FRR
   applications.  Other approaches are possible, but they are not
   specified in this document.
 ===========

15.  IANA Considerations

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

[CB]  Since the MRT Profile value can be carried in ISIS or OSPF (with corresponding documents in those WGs), and the MPLS LDP MT-ID values corresponding red and blue MRT FEC for the Default profile are in a document in the MPLS WG, the current document seems like a reasonable place to define a common registry in a protocol neutral document, and allow the protocol specific documents to reference it.

[CB] I changed the security considerations section to read as below.

   In general, MRT forwarding paths do not follow shortest paths.  The
   transit forwarding state corresponding to the MRT paths is created
   during normal operations (before a failure occurs).  Therefore, a
   malicious packet with an appropriate header injected into the network
   from a compromised location would be forwarded to a destination along
   a non-shortest path.  When this technology is deployed, a network
   security design should not rely on assumptions about potentially
   malicious traffic only following shortest paths.

   It should be noted that the creation of non-shortest forwarding paths
   is not unique to MRT.
--------------------

[CB]  I added the following section to address this.

14.  Operations and Management Considerations

   An implementation SHOULD provide an operator with the ability to test
   MRT paths with OAM traffic.  For example, when MRT paths are realized
   using LDP labels distributed for topology-scoped FECs, an
   implementation can use the MPLS ping and traceroute as defined in
   [RFC4379] and extended in [RFC7307] for topology-scoped FECs.

===========

---

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

Rob,

Thanks for your feedback.  I added the following text to clarify how the alternates computed by MRT can be used together with alternates produced by other FRR technologies.  I also added text to clarify how MRT allows for the specification of different profiles which will generally produce different paths.

---------------------

15.  Applying Policy to Select from Multiple Possible Alternates for FRR

   For a given topology, GADAG root, and profile, MRT will provide a
   node-protecting alternate path from each PLR to each destination for
   any single link or node failure, if such a path exists.  Therefore,
   an implementation may choose to only use the alternates determined by
   MRT to provide 100% FRR coverage.

   However, it may be desirable to allow an operator to use MRT
   alternates together with alternates provided by other FRR
   technologies.  A policy-based alternate selection process can allow
   an operator to select the best alternate from those provided by MRT
   and other FRR technologies.  As an example, it may be desirable to
   implement a policy where a node-protecting LFA (if it exists for a
   given failure mode and destination) is preferred over a given MRT
   alternate.  [I-D.ietf-rtgwg-lfa-manageability] discusses many of the
   potential criteria that one might take into account when evaluating
   different alternates for selection.

   Note that future documents may define MRT profiles in addition to the
   default profile defined here.  Different MRT profiles will generally
   produce red and blue paths with different properties.  An
   implementation may allow an operator to use different MRT profiles
   instead of or in addition to the default profile. 

----------------------

I hope this helps to clarify that MRT can be used either alone, or with other FRR technologies.  

I also want to comment on the fact that remote LFA produces multiple alternates to choose from.  With respect to determining if an alternate provides node protection or not, the fact that remote LFA computes many possible alternate paths could be viewed as a drawback, as opposed to an advantage.    For a given PLR and failure mode and destination, in general it will be the case that many nodes qualify as PQ nodes.  In order to determine if the complete repair path from PLR to PQ-node and PQ-node to destination is node-protecting, additional computation is needed.  The most efficient approach seems to be to run a forward SPF from the PQ-node being evaluated.   In some topologies, it is not uncommon for many nodes to qualify as PQ nodes.  In order to avoid spending too much time churning away at running forward SPFs rooted at PQ-nodes, some implementations may find it useful to limit the number of PQ nodes evaluated for node-protection.

By comparison, for roughly the computational cost of evaluating three PQ nodes for node-protection, MRT produces a path which is guaranteed to be node-protecting, if node protection is possible.  In cases where node-protection and maximum coverage is important, it seems reasonable to give operators the option of having an efficient means of generating a node-protecting path as opposed to the trial and error approach of evaluating large numbers of PQ nodes, which may or may not ultimately provide a node-protecting path.

Thanks,
Chris

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Monday, December 14, 2015 11:32 AM
To: Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; Stewart Bryant <[email-masked]>
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture

Hi Stewart, Authors,
 
On 3 December 2015 at 11:03:27, Stewart Bryant ([email-masked](mailto:[email-masked])) wrote:
> 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.

Kind regards,
r.

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

---

From: Rob Shakir <[email-masked]>
Date: Mon, 21 Dec 2015 15:46:39 +0000

Chris,

Thanks for the clarification around the fact that MRT can be run as part of a multi-technology approach. I wouldn’t endorse such an approach operationally — why run multiple technologies alongside each other that one must understand vs. a single one that could meet multiple requirements - but some operators may find such an approach useful.

On 21 December, 2015 at 2:47:20 PM, Chris Bowers ([email-masked]) wrote:

By comparison, for roughly the computational cost of evaluating three PQ nodes for node-protection, MRT produces a path which is guaranteed to be node-protecting, if node protection is possible. In cases where node-protection and maximum coverage is important, it seems reasonable to give operators the option of having an efficient means of generating a node-protecting path as opposed to the trial and error approach of evaluating large numbers of PQ nodes, which may or may not ultimately provide a node-protecting path. 
I feel this analysis misses a fundamental point — ‘cost’ does not equate only to the number of cycles that we must spend to find an alternate. Instead we need to consider the whole picture. The question one really needs to consider here is whether the “cost” of using CPU cycles is something that we want to optimise for, over the cost of investing in operational expertise/tooling to ensure manageability and capacity.

Much of the work that LFA manageability and TI-LFA do is to make flows align with what is “expected” to happen in the network - such that it is easy to understand for operational personnel, but also, it does not drive investment in new capacity which is used *only* in repair scenarios (such investment is generally required IMHO, in order to not congest and degrade all application traffic during that repair). 

In my experience (and of course, YMMV), optimising for the latter operational reasons is very much worth spending more cycles on the control-plane, especially now that there are tending to be more resources available there. I think characterisations such as the one above are very academically interesting, but I find that in this case, that has less relevance when we come to actually operating a network.

I think there’s interesting work here, but I’ll continue to struggle with whether it really is usable operationally.

Regards,

r.

---

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

Hi Chris

Thanks for addressing my comments.

I will trim the email to just the areas that need fur

SB> I think the assumptions are for example:
- Single link or node failure
- Can't remember if you have the means to deal with SRLG
- LF technique is in place
- method of detecting situation outside your assumptions is in place

In other words, you need to describe assumptions you are making
making about the environment in which this solution works. Whilst
RFC5714 talks around the problem, a solution needs to be
quite specific about when it breaks, (a) to alert the operator, and
(b) to make sure that the solution considers the consequences of
operating outside the specified envelope.

> [CB]  I don’t understand the distinction that you suggest noting.  The MRT computation run at each source node produces a distinct red and blue tree for each destination node with each tree rooted…

SB> Maybe I am confused. As I recall you need to determine a single 
lowpoint as the starting
point for your repair topologies. Doesn't that mean that effectively 
become the root of a
pair of repair trees?

Also the low point can move under certain circumstances, and I thing 
that will impact
the repair topology.

>                   Summary Comparison of IP/LDP FRR Methods
SB> I think this deserves consideration. The route computational world 
has moved
on since this work was started.

> SB> comparison section earlier in the document.
SB> No comment on the above?

---

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

On 21/12/2015 15:46, Rob Shakir wrote:
> Chris,
>
> Thanks for the clarification around the fact that MRT can be run as 
> part of a multi-technology approach. I wouldn’t endorse such an 
> approach operationally — why run multiple technologies alongside each 
> other that one must understand vs. a single one that could meet 
> multiple requirements - but some operators may find such an approach 
> useful.
>
> On 21 December, 2015 at 2:47:20 PM, Chris Bowers ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>> I also want to comment on the fact that remote LFA produces multiple 
>> alternates to choose from. With respect to determining if an 
>> alternate provides node protection or not, the fact that remote LFA 
>> computes many possible alternate paths could be viewed as a drawback, 
>> as opposed to an advantage. For a given PLR and failure mode and 
>> destination, in general it will be the case that many nodes qualify 
>> as PQ nodes. In order to determine if the complete repair path from 
>> PLR to PQ-node and PQ-node to destination is node-protecting, 
>> additional computation is needed. The most efficient approach seems 
>> to be to run a forward SPF from the PQ-node being evaluated. In some 
>> topologies, it is not uncommon for many nodes to qualify as PQ nodes. 
>> In order to avoid spending too much time churning away at running 
>> forward SPFs rooted at PQ-nodes, some implementations may find it 
>> useful to limit the number of PQ nodes evaluated for node-protection.
>>
>> By comparison, for roughly the computational cost of evaluating three 
>> PQ nodes for node-protection, MRT produces a path which is guaranteed 
>> to be node-protecting, if node protection is possible. In cases where 
>> node-protection and maximum coverage is important, it seems 
>> reasonable to give operators the option of having an efficient means 
>> of generating a node-protecting path as opposed to the trial and 
>> error approach of evaluating large numbers of PQ nodes, which may or 
>> may not ultimately provide a node-protecting path.
>
> I feel this analysis misses a fundamental point — ‘cost’ does not 
> equate only to the number of cycles that we must spend to find an 
> alternate. Instead we need to consider the whole picture. The question 
> one really needs to consider here is whether the “cost” of using CPU 
> cycles is something that we want to optimise for, over the cost of 
> investing in operational expertise/tooling to ensure manageability and 
> capacity.
>
I certainly agree with that statement. Compute limit is much less of a 
problem than when any of this work was started.

Stewart

> Much of the work that LFA manageability and TI-LFA do is to make flows 
> align with what is “expected” to happen in the network - such that it 
> is easy to understand for operational personnel, but also, it does not 
> drive investment in new capacity which is used *only* in repair 
> scenarios (such investment is generally required IMHO, in order to not 
> congest and degrade all application traffic during that repair).
>
> In my experience (and of course, YMMV), optimising for the latter 
> operational reasons is very much worth spending more cycles on the 
> control-plane, especially now that there are tending to be more 
> resources available there. I think characterisations such as the one 
> above are very academically interesting, but I find that in this case, 
> that has less relevance when we come to actually operating a network.
>
> I think there’s interesting work here, but I’ll continue to struggle 
> with whether it really is usable operationally.
>
> Regards,
>
> r.
>