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

[Stewart Bryant <[e-mail]>]

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