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

[Stewart Bryant <[e-mail]>]

Resending with the correct draft alias

On 07/12/2015 11:07, Stewart Bryant wrote:
> 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.
>> ===========
>