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

[Stewart Bryant <[e-mail]>]

I largely agree with Bruno, although I have some questions about
the SR approach as well.

Please see inline.

Stewart

On 08/12/2015 14:49, [e-mail] wrote:
>
> Hi Anil,
>
> Since you have cited me, I’m probably forced to join the discussion.
>
> As a disclaimer, as already expressed, for spring capable networks, I 
> personally believe that TI-LFA is the best solution. So I’m not sure 
> that you involved the right guy to support MRT ;-)
>
SB> A solution based on source routing is a good solution, but I have 
reservations about the particular solution given the observaion earlier 
in this thread that you cab get looping repairs. However as I noted 
there the fix is quite simple.
>
> As a general comment, we indeed have multiple FRR solutions ( e.g. 
> TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop 
> link protection, end to end RSVP-TE FRR (multiple flavors and new 
> additional extensions discussed in MPLS WG), some mid point to some 
> other mid points RSVP-TE…) plus discussed in multiple WG (RTGWG and 
> MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING 
> (although TI-FRR could possibly also be discussed in RTGWG rather than 
> MPLS))
>
> So there may be a question whether the IETF:
>
> a) is fine with documenting multiple/many, independent solutions,
>
> b) is fine with many solutions but want to evaluate them to see which 
> one is the best fit depending on the deployment case
>
> c) whether we need to choose N solutions based on technical merits
>
> Personally, I don’t really have a strong preference, but they seem 
> ranked from faster/easier to longer/harder. So far I assumed that “a” 
> had been chosen. May be “b” would make sense, assuming I’m not the one 
> doing the job ;-) . I’m afraid “c” would burn many times, for limited 
> benefits. (I can already foresee some lengthy discussions just to pick 
> the “right” value for N, before even starting the technical evaluation)
>
> Probably the easiest path, and in particular for the mrt draft, would 
> be to avoid comparing solutions, and definitely avoid saying that MRT 
> is the best solution. (And I’m not saying the draft says that, but you 
> do in the below email) Because IMHO, comparisons are difficult, long 
> and putting this in the mrt draft is a risk to delay it (possibly 
> forever). But I’m also fine with discussing the comparisons. It’s 
> really up to MRT authors.
>
SB> My interpretation of the text in the draft is that it is making the 
claim that it is the best solution.
SB> My assertion is that this is not the case, and at the moment I hold 
that position for all of the
SB> candidate solutions, since all of them have limitations.
SB>
SB> I would propose (b) by only publishing the designs as informational 
and then anointing one or more
SB> as standard when we have significant deployment experience.

> At least I expect the choice to apply to all solutions (and not option 
> “a” when RLFA or MRT is discussed,and then option “c” when TI-LFA is 
> discussed)
>
> More inline [Bruno]
>
> *From**:*rtgwg [mailto:[e-mail]] *On Behalf Of *Anil 
> Kumar S N (VRP Network BL)
> *Sent:* Tuesday, December 08, 2015 1:07 PM
> *To:* Stewart Bryant; 
> [e-mail]; [e-mail]; 
> Alvaro Retana
> *Cc:* Mike Shand
> *Subject:* RE: WGLC for draft-rtgwg-mrt-frr-architecture
>
> 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] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[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
>
>         [Bruno] Let’s compare the solutions with the same assumptions.
>         If we are ready to support the cost of multiplying the size of
>         the FIB, Segment Routing could probably advertise 2 SIDs per
>         segments: one protected with FRR and one not protected. With
>         this, TI-LFA can use non protected segments and hence chose to
>         drop the packet in case of multiple unrelated failures.
>         (rather than risking loops in some cases, to gain protections
>         for unrelated failures in the other cases). For this TI-LFA
>         would need to double the number of FIB entries, while I think
>         that MRT triple it. Not to mention the choice is local and
>         possibly on a per destination.
>
SB> That is the right approach, but it is surely not that onerous. You 
only double the
SB> nodal segments, not the whole table. Same for the number of 
interfaces. I am
SB> not sure what the latest numbers are, but when I was studying this, 
the largest
SB> network we had was 500 nodes and k was about 8 to 10, so that would be
SB> just over 500 additional labels which seems pretty small.

>         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.
>
>         [Bruno] The point is that there are multiple/many metrics to
>         compare solutions. Picking a subset has a risk of biasing the
>         discussion/choices.
>

SB> Again, exactly my point.
>
>
>         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.
>
>         [Bruno] Yes and no. No TI-LFA does not require to compute the
>         extended P space. But yes, you need 1 SPF per protected
>         interface. Yes this is a cost, but this comes with a benefit
>         of taking the best/optimal path, for each case of failure.
>         IMHO 1 SPF per IGP interface seems a reasonable cost to me,
>         especially before the failure.
>

SB> Exactly, and to put that in perspective that is something like 
k(=10) * 20ms (SPF time).
SB> not a big deal.
>
>         If Node protection is desired then more computation is expected.
>
>         [Bruno] Fully agreed. But this gets topology dependent.
>
>         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.
>
>         [Bruno] “very simple”. As a network provider, I’d rather have
>         the solution simple to compute/understand for the human and
>         complex to compute for the computer. Especially as human brain
>         is not following More’s law.
>
>         Yes “simple” is difficult to measure, but I’m pretty sure that
>         if you pick 10 regulars people, give them a network topology
>         and ask them what would be the network behavior in case of
>         failure, then would find TI-LFA algo easier than the MRT one.
>
SB> They would find any SPF solution easier to follow, since they are 
familiar with the
SB> concept of adding up the metrics from the point where the packet is.
SB>
SB> With MRT they have to figure this out based on the global topology, 
not the local fragment.
>
>         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.
>
>         [Bruno] My point is that this is one metric among many. And
>         possibly not the most important.
>
>         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
>
>         [Bruno] Assuming you still need people to run and troubleshoot
>         the network when something goes wrong, they need to understand
>         the
>
>         network. Many be your point is that at some point, these
>         people may be softwarized in the SDN, but I’m afraid I can’t
>         see that far in the future.
>
>         But I don’t feel there is much overhead compared to R-LFA or
>         TI-LFA
>
>         [Bruno] We could discuss the R-LFA vs MRT case, but IMHO it’s
>         much easier to understand TI-LFA behavior than MRT or RLFA one.
>
>         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,
>
>         [Bruno] I disagree.
>
>         If administrator know what is GADAG, he could easily figure
>         out  what would be alternate path visually for an extent.
>
>         [Bruno] I’m not that familiar with MRT, but that sound like
>         ‘if the operator know the path, then he can figure out the
>         alternate path’. Sure, but this only move the question 1 step
>         further: how do the operator know the GADAG in a given topology?
>
>         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.
>
>         [Bruno] TI-LFA follows the regular Post Convergence IGP
>         shortest path. I can’t see what would be more simpler (there
>         is no new path/algo)
>

SB> I do have some concerns about this, but we should take those to a 
different thread.
SB> Specifically the paths are only aligned from the PLR, and not from 
the point of entry
SB> into the network, and thus I do not understand what advantage this 
constraint has
SB> in practice.
>
>         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.
>
>         MRT is quite different from traditional FRR technologies,
>         which really has unique positive qualities.
>
>         [Bruno] In which case it will be easy for you to demonstrate.
>
>         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.
>
>         ============
>
>         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.
>
>         ============
>
>         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.
>
>         [Bruno] For TI-LFA link protection, assuming the metric are
>         symmetric, you can mathematically prove that the maximum
>         number of additional labels to push is 2. For node protection
>         this topology dependent and unbounded in theory. In practice,
>         we have run simulation and for our networks the maximum number
>         of labels is 4 (and if could can only push 3 labels, you only
>         loose 0,02% of coverage). cfMPLS World Congress 2015 presentation.
>
SB> So - at this is really a question for the WG as a whole, is the 
symmetry constraint in or out?
SB> I think the MRT team are asserting that the symmetry constraint is 
not being applied, and
SB> indeed this is a basis for some of their own assertions.
SB>
SB> A symmetry constraint would be a major and useful constraint in 
simplifying the solution design.
>
>         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.
>
>         [Bruno] +1 It’s indeed a trade-off on multiple metrics. IMHO
>         it’s clear MRT is not always the best.
>
>
>
>         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 hassmall label stack support etc...
>
>         [Bruno] access device are usually deployed in simple
>         topologies, replicated N times. e.g. U,V, ring. In those 3
>         topologies, the access device has only 2 IGP links, which mean
>         that TI-LFA link protection needs 1 SPF, typically 0 to 1
>         additional label to push, and typically link protection will
>         offer de facto node protection.
>
>         May be to prove the point Comparison section is needed J
>
>         [Bruno] definitely needed. I’m not sure that a section will be
>         enough. I’d rather see a research paper.
>

SB> Well in the IETF context it needs a draft -> RFC.
SB> However it would be acceptable in my view to develop and deploy the 
various solutions,
SB> do the analysis, and then make a statement about which the IETF 
endorse through
SB> the standards process.
>
>         =============
>
>         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.
>
>         ===========
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorization.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
> Thank you.