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

[Stewart Bryant <[e-mail]>]

Please see more comments inline

- Stewart

On 08/12/2015 12:07, Anil Kumar S N (VRP Network BL) wrote:
>
> Hi Stewart,
>
> Request you to see inline for reply.
>
> Thanks & Regards
>
> Anil S N
>
> “Be liberal in what you accept, and conservative in what you send” - 
> Jon Postel
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* 07 December 2015 19:29
> *To:* Anil Kumar S N (VRP Network BL); 
> [e-mail]; [e-mail]; 
> Alvaro Retana
> *Cc:* Mike Shand
> *Subject:* Re: WGLC for draft-rtgwg-mrt-frr-architecture
>
> 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.
>
>         [ANIL 2 >> ]
>
>         I remember Bruno pointed out a simple topology with multiple
>         failure can cause LOOP in SR,
>
>         I am yet to understand Not Via
>
>         Below is the topology, Where all links have a metric of 10,
>         except AD which has 100
>
>         For the traffic from A to C, if both AC and BD links fails at
>         the same time (and were not identified as SRLG),
>
>         there will be a loop between A and B. (and funnily (is it? ;-)
>         ) as packets are looped,
>
>         the label stack seems to increase to “infinity” as additional
>         P nodes (alternatively C and D) are used.
>
>         A – B
>
>         |  \  |
>
>         C – D
>
>         So multiple failure, the behavior could be undesirable. There
>         could many unforeseen topologies
>
>         Where the extent of multiple failure and behavior might be
>         undesired.  Please check NV against this topology.
>
>         MRT guarantees one thing for sure; if in case of multiple
>         failure Packets would be dropped but it will not be looped.
>
>         Which is very important, looping congests line card and will
>         be trigger for further failures. J
>
SB1> We addressed this problem in NV by not repairing repairs. At A the 
packet would
SB1> have gone into a tunnel from A to C via B and D with address C 
not-via AC.
SB1> B and D would of course populate their forwarding tables with the 
normal next
SB1> hop for the NV address, but instead of having a repair for the 
address, they would
SB1> have a drop for it. The result is unconditional safety of the type 
you seek with MRT.

SB1> I assume that the SR folks are trying to use the same segment 
identifiers for both
SB1> traffic engineering and repair. This is surely a mistake. By using 
a different set of identifiers
SB1> for repair, and not repairing packets that arrive with a repair SI, 
i.e. following the
SB1> the approach that we proposed in NV the SR approach would also be 
unconditionally
SB1> safe against an unexpected failure.
>
>           
>
>         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.
>
>         [ANIL 2 >> ]
>
>         Let’s compare TI-LFA and MRT computation constraints, I
>         believe MRT need less computation than TI-LFA
>
>         TI-LFA need to calculate Extended P-Space for set of
>         destination which used each other nexthop.
>
>         Number of SPF directly depends on Number of Neighbors. If Node
>         protection is desired then more computation is expected.
>
>         In contrary, MRT has to prepare a graph and select alternates.
>
>         If preparation of GADAG is considered as one SPF then it boils
>         down to be very simple.
>
>         Since GADAG root is fixed, If central controller in place, if
>         controller can collect link state information from topology
>
>         Using BGP LS or by forming IGP peer. The GADAG calculation can
>         be delegated to controller.
>
>         Only alternate information can be downloaded by Controller.
>         This cannot be achieved
>
>         With this ease in case where LFA calculation done for tree
>         rooted at every PLR
>
>         My point is measurement can be of any form/measurement units,
>         MRT has computation advantage but with
>         implementation/understanding/algorithm complexity.
>
SB1> If we are going to publish a comparison, then it needs to be 
complete, objective, and
SB1> we need to properly understand what the true importance is.

SB1> My contention, and surely the big-data and machine learning people 
will support this
SB1> is that the compute power in a data center is so large that you can 
disregard many
SB1> historic concerns about compute limitation. If the repairs are 
being computed in an
SB1> SDN controller we have massive compute power and huge storage and 
so need to be
SB1> far less concerned with the compute limitations that have 
constrained our thinking.

SB1> So in this particular case what is being done is to accept 
limitations in the repair
SB1> strategy in order to minimise computational overhead, at a time 
when we are moving
SB1> into a world where computational overhead is no longer a limiting 
factor.

SB1> BTW as I pointed out in another email, the GADAG root is not fixed 
in the event of
SB1> the failure of that node or the introduction of a new node that 
becomes the minimum.
>
>           
>
>         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.
>
>         [ANIL 2 >> ]
>
>         In fact , MRT provides less operation complexity, If
>         administrator know what is GADAG, he could easily figure out
>          what would be alternate path visually for an extent.
>
>         In simple case, if primary path matches with blue then
>         alternate path is red. The same cannot be expected with R-LFA
>         or TI-LFA.
>
>         It’s even difficult to send OAM packets to verify backup path
>         in case of R-LFA and TI-LFA.
>
>         For MRT administrator can send OAM packets on RED or on BLUE
>         path to a specific path.
>
SB1> The first question I have is how may admins know what a GADAG is? 
Remember up until now
SB1> all you needed to think about was what is the shortest path from 
where the packet currently
SB1> is to the destination.

SB1> I do not understand your comment about OAM. You can send OAM over 
the repair path
SB1> with any of the repair techniques. You have to send it from the 
PLR, but what is wrong with
SB1> that?

>
>         MRT is quite different from traditional FRR technologies,
>         which really has unique positive qualities.
>
>         Only thing I feel which is lacking in MRT is capability to
>         handle multiple failure and that should not be only criteria
>         to reject a good protocol J
>
>         Hope its gets due appreciation for its unique capabilities J
>
>         ============
>
>           
>
>           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.
>
>         [ANIL 2 >> ] I am not an author, I wish I would; since I like
>         this protocol J,
>
>         I am sure authors will update it.
>

SB1> I hope so, although so far they have been very quiet.
>
>         ============
>
>           
>
>         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.
>         [ANIL 2 >> ] I request you to elaborate this point. I didn’t
>         understand.
>
>         As far I can say, If network has no cut vertex or cut link.
>         MRT can provide alternate path for single failure without any
>         issue.
>
>         Cut-vertex and Cut-Link is a issue for any FRR technologies.
>         So it finally boils down to multiple failure which MRT doesn’t
>         support.
>
>           
>
SB1> In the event of a single failure there is no problem, but the draft 
does not make that constraint clear.
SB1> In the event of a double serial failure (which some of the other 
methods can handle) then you
SB1> may find that there exists a path to every destination in base, but 
because one of the paths needed
SB1> was in red and the other in blue you cannot repair.

>         ============
>
>           
>
>         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.
>
>         [ANIL 2 >> ] MRT can be a best trade off in cases where ,
>         Network device has low computing powers but better forwarding
>         capacity (access devices),
>
>         Network devices has small label stack support etc...
>
>         May be to prove the point Comparison section is needed J
>
SB1> If that is the constraint, then it needs to be made clear up front, 
and as I noted
SB1> earlier in the thread, the comparison needs to be expanded to be 
complete
SB1> and objective.


>           
>
>         =============
>
>           
>
>         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.
>
>           
>
>           
>
>         ===========
>