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

["Anil Kumar S N (VRP Network BL)" <[e-mail]>]

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> 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 >>]  ☺ Its not wrong to claim MRT consumes much less computation compared to other FRR technologies.

Be it SDN controlled or distributed.



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 ☺

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



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



 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.



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



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



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



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



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



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.





===========