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

[Stewart Bryant <[e-mail]>]

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:
>
> 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:[e-mail]] *On Behalf Of *Stewart Bryant
> *Sent:* 04 December 2015 02:22
> *To:* [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Alvaro Retana
> *Subject:* WGLC for draft-rtgwg-mrt-frr-architecture
>
> 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.
> [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> 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.
> 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?
> [Anil >>] JIts not wrong to claim MRT consumes much less computation 
> compared to other FRR technologies.
> Be it SDN controlled or distributed.

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.
>   
> 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.
> [Anil >>] As you stated in previous comment, Moving to SDN world 
> overhead can be offloaded J
> 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.

> ============
>   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.
> [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.
SB> This needs to be highlighted, together with the mechanism that you 
will use
SB> to abandon the LF reconvergence.
> ============
> 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"
> [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
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.
> ============
> 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.
> [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
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.
> =============
> 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.
> [Anil >>] I agree to move to 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.
> [Anil >>] I agree to move to comparison section.
>     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.
> ===========