Subject: Re: candidate-draft-ietf-rtgwg-remote-lfa-03.txt

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Nov 2013 16:46:27 +0000

On 29/10/2013 15:17, [email-masked] wrote:

Stephane

Thank you for your comments.
>
>
>     Q-space        Q-space is the set of routers from which a specific
>                    router can be reached without any path (including
>                    equal cost path splits) transiting the protected link.
>
> [SLI] Should swap Q-Space and PQ node definition placement, as PQ node refers to Q-Space definition.
SB> Yes, but the list is in alphabetical order rather than in
SB> declarative order.
SB> I suggest that alphabetical is a normal ordering for
SB> such an index of terms.
>
> 2.  Introduction
>
>     RFC 5714 [RFC5714] describes a framework for IP Fast Re-route and
>     provides a summary of various proposed IPFRR solutions.  A basic
>     mechanism using loop-free alternates (LFAs) is described in [RFC5286]
>     that provides good repair coverage in many
>     topologies[I-D.filsfils-rtgwg-lfa-applicability], especially those
>     that are highly meshed.  However, some topologies, notably ring based
>     topologies are not well protected by LFAs alone.  This is illustrated
>     in Figure 1 below.
>     
>     [SLI] Replace [I-D.filsfils-rtgwg-lfa-applicability] by RFC6571
Good catch - done.
>     
>
>               S---E
>              /     \
>             A       D
>              \     /
>               B---C
>
>
>
>
> Bryant, et al.            Expires May 01, 2014                  [Page 3]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>                       Figure 1: A simple ring topology
>
>     If all link costs are equal, the link S-E cannot be fully protected
>     by LFAs.  The destination C is an ECMP from S, and so can be
>     protected when S-E fails, but D and E are not protectable using LFAs
>
>     This draft describes extensions to the basic ([SLI] add "basic LFA repair ...") repair mechanism in
>     which tunnels are used to provide additional logical links which can
>     then be used as loop free alternates where none exist in the original
>     topology.  For example if a tunnel is provided between S and C as
>     shown in Figure 2 then C, now being a direct neighbor of S would
>     become an LFA for D and E. The non-failure traffic distribution is
>     not disrupted by the provision of such a tunnel since it is only used
>     for repair traffic and MUST NOT be used for normal traffic.
>
>            S---E
>           / \   \
>          A   \   D
>           \   \ /
>            B---C
>
>                      Figure 2: The addition of a tunnel
>
>     The use of this technique is not restricted to ring based topologies,
>     but is a general mechanism which can be used to enhance the
>     protection provided by LFAs.  A study of the protection achieved
>     using remote LFA in typical service provider core networks is
>     provided in Section 8, and a side by side comparison between LFA and
>     remote LFA is provided in Section 8.4.
>
>     Remote LFA is suitable for incremental deployment within a network,
>     including a network that is already deploying LFA.  Computation of
>     the repair path is relatively simple, and takes place exclusively on
>     the repairing node.  In MPLS networks the targeted LDP protocol
>     needed to learn the label binding at the repair tunnel endpoint is a
>     well understood and widely deployed technology.
>
>     This technique describes in this document is directed at providing
>     repairs in the case of link failures.  Considerations regarding node
>     failures are discussed in Section 6.
>
> 3.  Repair Paths
>
>     As with LFA FRR, when a router detects an adjacent link failure, it
>     uses one or more repair paths in place of the failed link.  Repair
>     paths are pre-computed in anticipation of later failures so they can
>     be promptly activated when a failure is detected.
>
>
>
>
> Bryant, et al.            Expires May 01, 2014                  [Page 4]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>     A tunneled repair path tunnels traffic to some staging point in the
>     network from which it is assumed that, in the absence of multiple
>     failures, it will travel to its destination using normal forwarding
>     without looping back.  This is equivalent to providing a virtual
>     loop-free alternate to supplement the physical loop-free alternates.
>     Hence the name "Remote LFA FRR".  When a link cannot be entirely
>     protected with local LFA neighbors, the protecting router seeks the
>     help of a remote LFA staging point.
>     
>     [SLI] Not a good idea to seek rLFA only when LFA is not available (see manageability)
SB> This now says:
In its simplest form, when a link cannot be entirely protected with 
local LFA
neighbors, the protecting router seeks the help of a remote LFA staging 
point.
Network manageability considerations may lead to a repair strategy that
uses a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability]

>
> 3.2.  Tunnel Requirements
>
>
>
>     automatically established as a basic property of LDP behavior.  The
>     performance of the encapsulation and decapsulation is also excellent
>     as encapsulation is just a push of one label (like conventional MPLS
>     TE FRR) and the decapsulation occurs naturally at the penultimate hop
>     before the PQ node.
>    [SLI] Ok the tunnel is already available, but you need some time to establish the protection (TLDP session establishment + label learning time).
> 	This is important to precise this.

SB> The text now says:

The performance of the encapsulation and decapsulation is efficient as 
encapsulation
is just a push of one label (like conventional MPLS TE FRR) and the 
decapsulation
occurs naturally at the penultimate hop before the PQ node. In the 
control plane,
a targeted LDP (TLDP) session is needed between the repairing node and the
repair tunnel endpoint, which will need to be established and the labels 
processed
before the tunnel can be used. The time to establish the TLDP session 
and acquire
labels will limit the speed at which a new tunnel can be put into 
service, but this
will not be a problem in normal operation.
> 	
>     When a failure is detected, it is necessary to immediately redirect
>     traffic to the repair path.  Consequently, the repair tunnel used
>     must be provisioned beforehand in anticipation of the failure.  Since
>     the location of the repair tunnels is dynamically determined it is
>     necessary to establish the repair tunnels without management action.
>     [SLI] s/management action/manual provisionning action/ , as management may be needed to tweak the best tunnel tailend.
SB> I have changed this to:
Since the location of the repair tunnels is dynamically determined it is
necessary to automatically establish the repair tunnels.

This covers both protocol and NMS and excludes humans.
>   
> 4.2.1.  Computing Repair Paths
>
>     In the case of Figure 1 the Q-space
>     comprises nodes C and D only.  Expressed in cost terms the set of
>     routers {Q} are those for which the shortest path cost E->Q is
>     strictly less than the shortest path cost E->S->Q.
>     
>     [SLI] Would it be Q->E less than Q->S->E

SB> Thanks

> 4.2.2.  Extended P-space
>
>
>
>     Another way to describe extended P-space is that it is the union of (
>     un-extended ) P-space and the set of destinations for which S has a
>     per-prefix LFA protecting the link S-E. i.e. the repair tunnel end
>     point can be reached either directly or using a per-prefix LFA.
>
>     	[SLI] Lack of precision about independancy of rLFA and LFA alternate choice is rLFA is using extended P space node.
> 	I would propose :
> 	
> 	"Even if extended P-space would be composed on nodes reachable through a per-prefix LFA, this does not conclude that the rLFA would inherit the best LFA to reach the PQ:
> 	rLFA an LFA MUST be completely independant. In other words, if S has N1 and N2 as LFAs to protection a destination P, and S wants to use P as PQ to protect a destination D.
> 	S must be able to program N1 as LFA to reach P and P through N2 to reach D for manageability reasons (refer to Section 9)."

SB> We are talking about different things. This is not about whether
SB> or not we use LFA and RLFA together. This is another way
SB> of expressing extended P-space. Extended P-space
SB> is everything that E can reach on its own + everything that
SB> it can reach by forcing the first hop to a directly connected
SB> neighbour - which is what a per-prefix LFA is. The
SB> para is purely tutorial, and can be removed.

>
>
> 	
> 4.2.3.  Selecting Repair Paths
>
>     The mechanisms described above will identify all the possible repair
>     tunnel end points that can be used to protect a particular link.  In
>     a well-connected network there are likely to be multiple possible
>     release points for each protected link.  All will deliver the packets
>     correctly so, arguably, it does not matter which is chosen.  However,
>     one repair tunnel end point may be preferred over the others on the
>     basis of path cost or some other selection criteria.
>
>     There is no technical requirement for the selection criteria to be
>     consistent across all routers, but such consistency may be desirable
>     from an operational point of view.  In general there are advantages
>     in choosing the repair tunnel end point closest (shortest metric) to
>     S. Choosing the closest maximises the opportunity for the traffic to
>     be load balanced once it has been released from the tunnel.  For
>     consistency in behavior is RECOMMENDED that member of the set of
>     routers {P} with the lowest cost S->P be the default choice for P. In
>     the event of a tie the router with the lowest node identifier SHOULD
>     be selected.
>     
>     [SLI] Need to replace P by PQ : "For
>     consistency in behavior is RECOMMENDED that member of the set of
>     routers {PQ} with the lowest cost S->PQ be the default choice for PQ."
>     
SB> Done.
>
> 4.3.  A Cost Based RLFA Algorithm
>
>     The preceding text has mostly described the computation of the remote
>     LFA repair point (PQ) in terms of the intersection of two
>     reachability graphs computed using SPFs.  This section describes a
>     method of computing the repair point using a cost based algorithm.
>     
>     [SLI] "repair point" is confusing as a repair point is a PLR and here we talk about PQ.
>     Could we use "Remote LFA" instead ?
SB> It now says:

The preceding text has mostly described the computation of the remote 
LFA repair
target (PQ) in terms of the intersection of two reachability graphs 
computed using
SPFs. This section describes a method of computing PQ using a cost based 
algorithm.

The first sentence reminds the reader what PQ is, so I think this is clear.
>     
>     The pseudo-code provides in this section avoids unnecessary SPF
>     computations, but for the sake of readability, it does not otherwise
>     try to optimize the code.  Unconventionally, but for clarity, we
>     provide the main algorithm followed its procedures.  In this
>     description D_opt(a,b) is the shortest distance from node a to node b
>     as computed by the SPF.
>
> 	[SLI] Changing the pseudocode and create a remote LFA function as step of rLFA computation are here mixed with subfunctions.
> 	Proposal here :

SB> The problem is with hitting the 72 col limit.
SB> I have marked this with comments
SB> Hopefully this is now clear.
>
> 	// Remote LFA computation function
> 	
> 	main {
> 	  //////////////////////////////////////////////////////////////////
>        //
>        // We have already computed the forward SPF from self to all nodes
>        // y in network and thus we know D_opt (self, y). This is needed
>        // for normal forwarding.
>        // However for completeness.
>
>        Compute_and_Store_Forward_SPF(self)
>
> 	  // Need to compute rSPF(self) to compute cost based Q Space (done only one time)
> 	  Compute_and_Store_Reverse_SPF(self)

SB> This was only done once in the original.
> 		
>        // To extend P-space we compute the SPF at each neighbour except
>        // the neighbour that is reached via the link being protected.
>        // We will also need D_opt(fail_intf.remote_node,y) so compute
>        // that at the same time.
>
>        foreach interface intf in self
>                Compute_and_Store_Forward_SPF(intf.remote_node)
> 		[SLI] I removed the Compute_Neighbor_SPFs as , IMHO, it complexifies the readability ...

SB> This is tricky, because whilst true, the implementation will
SB> need to know which are which since it normally needs to
SB> deal with them differently in the FIB code.
SB> However I have taken it out.

> 		
> 	  // Compute rLFA for each interface
> 	  foreach interface fail_intf in self
> 		Compute_RLFA(fail_intf)
> 	}
> 	
> 	Compute_RLFA(fail_intf) {
> 	
>        // Compute the set of nodes {P} reachable other than via the
>        // failed link
>
>        Compute_Extended_P_Space(fail_intf)
> 	[SLI] Adding "fail_intf" as parameter
SB> OK, although it was correct as a global.
> 	
>        // Compute the set of nodes that can reach the node on the far
>        // side of the failed link without traversing the failed link.
>
>        Compute_Q_Space(fail_intf)
> 	[SLI] Adding "fail_intf" as parameter

SB> See above
>
>        // Compute the set of candidate RLFA tunnel endpoints
>
>
>
>
> Bryant, et al.            Expires May 01, 2014                  [Page 9]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>        Intersect_Extended_P_and_Q_Space()
>
>        // Make sure that we cannot get looping repairs when the
>        // failure is worse than expected.
>
>        if (guarantee_no_looping_on_worse_than_protected_failure)
>            Apply_Downstream_Constraint()
> }
>
>
> 	// Sub functions
> 	
>        /////////////////////////////////////////////////////////////////
>        //
>        // This computes the SPF from root, and stores the optimum
>        // distance from root to each node y
>
>        Compute_and_Store_Forward_SPF(root)
>            Compute_Forward_SPF(root)
>            foreach node y in network
>                store D_opt(root,y)
>
> 	[SLI] I would add a comment to the function :
> 	
>        Compute_and_Store_Forward_SPF(root)
>            Compute_Forward_SPF(root)		// A SPF may already been in cache and so may be no need to recompute it
>            foreach node y in network
>                store D_opt(root,y)
SB> That was covered in my comment in main.

>
>        /////////////////////////////////////////////////////////////////
>        //
>        // The reverse SPF computes the cost from each remote node to
>        // root. This is achieved by running the normal SPF algorithm,
>        // but using the link cost in the direction from the next hop
>        // back towards root in place of the link cost in the direction
>        // away from root towards the next hop.
>
>        Compute_and_Store_Reverse_SPF(root)
>            Compute_Reverse_SPF(root)
>            foreach node y in network
>                store D_opt(y,root)
>
>
>
>
>
> Bryant, et al.            Expires May 01, 2014                 [Page 10]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>        /////////////////////////////////////////////////////////////////
>        //
>        // Calculate P space and then extend it by the P-spaces of each
>        // neighbour other than the one reachable via the link being
>        // protected. Note the strictly less than operator is needed to
>        // avoid ECMP issues.
>
>        Compute_Extended_P_Space()
>            foreach node y in network
>                y.in_extended_P_space = false
>                // Compute P-space
>                //
>                // Editor's note, I think that this if statement may be
>                // redundant since the foreach interface intf in self
>                // loop catches all cases.
> 			
> 			  [SLI] Yes, IMHO, this is redundant.
SB> I took it out
>                
> 			  //
>                // Editor's note D_opt(fail_intf.remote_node,y) requires
>                // an SPF from neighbour fail_intf.remote_node so did
>                // this as part of all neighbours SPF calculation
>                if (D_opt(self, y) <
>                        D_opt(self, fail_intf.remote_node) +
>                        D_opt(fail_intf.remote_node,y))
>                    y.in_extended_P_space = true
>                // Extend P-space to the P-spaces of all reachable
>                // neighbours
>                foreach interface intf in self
>                    if (intf.remote_node != fail_intf.remote_node)
>                        if ( D_opt(intf.remote_node, y) <
>                             D_opt(intf.remote_node, self) +
>                             D_opt(self,fail_intf.remote_node) +
>                             D_opt(fail_intf.remote_node,y) )
>                         y.in_extended_P_space = true
>
>
>
>        /////////////////////////////////////////////////////////////////
>        //
>
>        Compute_Q_Space(fail_intf)
>            // Compute the cost from every node the network to the
>            // node normally reachable across the failed link
>            Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
>
>            // Compute the cost from every node the network to self
>             [SLI] Need to be removed I putted it in main code (optimize number of SPF)
SB> It is fine here. Main does not need to know about this calc since
SB> it is not shared.
>
>            foreach node y in network
>                if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
>
>
>
> Bryant, et al.            Expires May 01, 2014                 [Page 11]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>                        D_opt(self,fail_intf.remote_node) )
>                    y.in_Q_space = true
>                else
>                    y.in_Q_space = false
>
>
>
>        /////////////////////////////////////////////////////////////////
>        //
>        // Compute set of nodes in both extended P-space and in Q-space
>
>        Intersect_Extended_P_and_Q_Space()
>            foreach node y in network
>                if ( y.in_extended_P_space && y.in_Q_space )
>                    y.valid_tunnel_endpoint = true
>                else
>                    y.valid_tunnel_endpoint = false
>
>
>
>        /////////////////////////////////////////////////////////////////
>        //
>        // A downstream route is one where the next hop is strictly
>        // closer to the destination. By sending the packet to a
>        // PQ node that is downstream, we know that if the PQ node
>        // detects a failure, it will not loop the packet back to self.
>        // This is useful when there are two failures, or a node has
>        // failed rather than a link.
>
>        Apply_Downstream_Constraint()
>            foreach node y in network
>                if (y.valid_tunnel_endpoint)
>                    Compute_and_Store_Forward_SPF(y)
>                    if ((D_opt(y,dest) < D_opt(self,dest))
>                        y.valid_tunnel_endpoint = true
>                    else
>                        y.valid_tunnel_endpoint = false
> 	[SLI] Based on my simulations, Compute_and_Store_Forward_SPF(y) would not be possible as number of y.valid_tunnel_endpoint == true is very high !
> 	So downstreamness could not be established so easily ... even if it's theorical working.
SB> Yes - well - whatever the consenus is I will leave it in or take it out

>            |    100    |
>           -P2---------P1-
>             \         /
>         1000 \       / 1000
>              PE1---PE2
>                  5
>
>                         Figure 3: Example SP topology
>
>     Clearly, full protection can be provided, using the techniques
>     described in this draft, by PE1 choosing P2 as a PQ node, and PE2
>     choosing P1 as a PQ node.
>     
>     [SLI] Would it be "PE1 choosing P1" and "PE2 choosing P2" ?
SB> yes, changed.
>
> 6.  Node Failures
>
>     When the failure is a node failure rather than a link failure there
>     is a danger that the RLFA repair will loop.  This is discussed in
>     detail in [I-D.bryant-ipfrr-tunnels].  In summary problem is that two
>     of more of E's neighbors each with E as the next hop to some
>     destination D may attempt to repair a packet addressed to destination
>     D via the other neighbor and then E, thus causing a loop to form.  As
>     will be noted from [I-D.bryant-ipfrr-tunnels], this can rapidly
>     become a complex problem to address.
>
>
>
>
>
>
> Bryant, et al.            Expires May 01, 2014                 [Page 13]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>     There are a number of ways to minimize the probability of a loop
>     forming when a node failure occurs and there exists the possibility
>     that two of E's neighbors may form a mutual repair.
>
>     1.  Detect when a packet has arrived on some interface I that is also
>         the interface used to reach the first hop on the RLFA path to PQ,
>         and drop the packet.  This is useful in the case of a ring
>         topology.
> [SLI] This has several drawbacks, especially this may cause some "legal packet" drops ...
>   
This needs fixing in the commentary text below.
> 	
>     2.  Require that the path from PQ to destination D never passes
>         through E (including in the ECMP case), i.e. only use node
>         protecting paths in which the cost PQ to D is strictly less than
>         the cost PQ to E plus the cost E to D.
>
>     3.  Require that where the packet may pass through another neighbor
>         of E, that node is down stream (i.e. strictly closer to D than
>         the repairing node).  This means that some neighbor of E (X) can
>         repair via some other neighbor of E (Y), but Y cannot repair via
>         X.
>
>     Case 1 accepts that loops may form and suppresses them by dropping
>     packets.  Dropping packets may be considered less detrimental than
>     looping packets.

SB> I have added "This approach may also lead to dropping some 
legitimate packets."
> Cases 2 and 3 above prevent the formation of a
>     loop, but at the expense of a reduced repair coverage and at the cost
>     of additional complexity in the algorithm to compute the repair path.
>
>     The probability of a node failure and the consequences of node
>     failure in any particular topology will depend on the node design,
>     the particular topology in use, and node failure strategy (including
>     the null strategy).  It is recommended that a network operator
>     perform an analysis of the consequences and probability of node
>     failure in their network, and determine whether the incidence and
>     consequence of occurrence are acceptable.
>
>     This topic is further discussed in
>     [I-D.psarkar-rtgwg-rlfa-node-protection].
>
> 7.  Operation in an LDP environment
>
>     Where this technique is used in an MPLS network using LDP [RFC5036],
>     S will need to push two labels onto the repair packet.  First it
>     needs to push PQ's label to the destination, and then it needs to
>     push its own label for PQ.
>     
>     [SLI] If S is transit node, it swaps incoming label to PQ's label to the dest and then push.
>     So to simplify, I would say : "S need to push an additional label onto the repair packet".

SB> It now says:
"and S is a transit node, S will need to swap the top label in the stack 
for PQ's
label to the destination, and to push its own label for PQ. "
>     
>     In the example Section 3.1 S already has
>     [SLI] The example is in Section 2
SB> Thanks - corrected the anchor
>     
>     the first hop (B) label for the PQ node (C) as a result of the
>     [SLI] Would it be "the first hop (A)" ?

SB> Yes.
>     
>     ordinary operation of LDP.  To get the PQ node (C) label for the
>     destination (D), S needs to establish a targeted LDP session with C.
>     The label stack for normal operation and RLFA operation is shown
>     below in Figure 4.
>
>
>
> Bryant, et al.            Expires May 01, 2014                 [Page 14]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>     +-----------------+     +-----------------+     +-----------------+
>     |    datalink     |     |    datalink     |     |    datalink     |
>     +-----------------+     +-----------------+     +-----------------+
>     | S's label for D |     | E's label for D |     | C's label for D |
>     +-----------------+     +-----------------+     +-----------------+
>     |    Payload      |     |    Payload      |     | B's label for C |
>     +-----------------+     +-----------------+     +-----------------+
>             X                       Y               |    Payload      |
>                                                     +-----------------+
>                                                              Z
>
>     X = Normal label stack packet arriving at S
>     Y = Normal label stack packet leaving S
>     Z = RLFA label stack to D via C as PQ node
>
> 	[SLI] In Z, would it be "A's label for C", as A is the nexthop to reach C from S.
SB> I think that actually there were two errors
SB> Here is what the stack needs to look like

+-----------------+ +-----------------+     +-----------------+
|    datalink     |     |    datalink     |     |    datalink |
+-----------------+     +-----------------+ +-----------------+
| S's label for D |     | E's label for D |     | A's label for C |
+-----------------+     +-----------------+ +-----------------+
|    Payload      |     |    Payload      |     | C's label for D |
+-----------------+     +-----------------+ +-----------------+
         X                       Y               |    Payload |
+-----------------+
                                                          Z

X = Normal label stack packet arriving at S
Y = Normal label stack packet leaving S
Z = RLFA label stack to D via C as PQ node

>
>                                   Figure 4
>
>     To establish an targeted LDP session with a candidate PQ node the
>     repairing node (S) needs to know what IP address PQ is willing to use
>     for targeted LDP sessions.  Ideally this is provided by PQ
>     advertising this address in the IGP in use.  Which address is used,
>     how this is advertised in the IGP, and whether this is a special IP
>     address or an IP address also used for some other purpose is out of
>     scope for this document and must be specified in an IGP specific RFC.
>
>     In the absence of a protocol to learn the preferred IP address for
>     targeted LDP, a tie-breaking mechanism is required.  Unless otherwise
>     configured, an LSR should attempt a targeted LDP session with the IP
>     address with the lowest numerical value advertised by the target LSR.
>     To determine the lowest numerical value the address is taken in
>     network byte order and cast to an integer of appropriate size.
>     
>     [SLI] I would suggest :
>     Unless otherwise
>     configured, an LSR should attempt a targeted LDP session by selecting the lowest internal /32 prefix advertised by the target LSR.
SB> That fails the IPv6 test !
SB> I think that "local IP address" is clear and version independent.
>     
>     [SLI] I would add also :
>     "If the TLDP session could not be established, no protection would be available until the establishment succeeds and a label for the destination has been learned from the PQ.
>     An implementation may advise the operator about the protection setup issue using any well known mechanism such as syslog or SNMP for example."
>     
SB> The text now says

"No protection is available until the TLDP session has been established
and a label for the destination has been learned from PQ. If for any
reason the TLDP session cannot not be established, an implementation
SHOULD advise the operator about the protection setup issue using
any well known mechanism such as syslog or SNMP."
>
>
>
>
>
> 8.3.  RLFA
>
>
>     In this study, RLFA is only used when necessary. i.e. when there is
>     at least one destination which is not reparable by a per destination
>     LFA, and a single PQ tunnel is used (if available) to repair traffic
>     to all such destinations.  The RLFA PQ points are computed using
>     extended P space and choosing the PQ node which has the lowest metric
>     cost from the repairing node.
>
>
>       +------+--------+--------+------+------+-------+-----+-----+------+
>       | topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 |
>       +------+--------+--------+------+------+-------+-----+-----+------+
>       |    1 | 99.7   | 53.3   | 21.2 |  295 |     3 |   1 |   5 |   14 |
>
>
>
> Bryant, et al.            Expires May 01, 2014                 [Page 17]
>
> Internet-Draft               Remote LFA FRR                 October 2013
>
>
>       |    2 | 97.5   | 52.4   | 0.2  |    7 |    40 |   0 |   0 |    2 |
>       |    3 | 99.999 | 58.4   | 0.7  |   63 |     5 |   0 |   1 |    5 |
>       |    4 | 99     | 74.8   | 16   | 1424 |    54 |   1 |   3 |   23 |
>       |    5 | 99.5   | 59.5   | 0.5  |  151 |     7 |   0 |   2 |    7 |
>       |    6 | 100    | 34.9   | 13.6 |   63 |     0 |   1 |   2 |    6 |
>       |    7 | 99.999 | 40.6   | 6.1  |   16 |     2 |   0 |   2 |    4 |
>       |    8 | 99.5   | 50.2   | 4.3  |  350 |    39 |   0 |   2 |   15 |
>       |    9 | 99.5   | 55     | 17.3 |  428 |     5 |   1 |   2 |   67 |
>       |   10 | 99.6   | 14.1   | 1    |   49 |     7 |   1 |   2 |    5 |
>       |   11 | 99.9   | 24.9   | 0.3  |   85 |     1 |   0 |   2 |    8 |
>       |   12 | 99.999 | 62.8   | 0.5  |  512 |     4 |   0 |   0 |    3 |
>       |   13 | 97.5   | 54.6   | 5.1  | 1188 |    95 |   0 |   2 |   27 |
>       |   14 | 100    | 48.6   | 0.7  |   79 |     0 |   0 |   2 |    4 |
>       +------+--------+--------+------+------+-------+-----+-----+------+
>
>
> 	 [SLi] Would be good to have the avg, and max number of PQs node available for a specific interface or globally for a node.
SB> That will not fit in the table and Mike has not given them to me.
SB> How critical is this, i.e. is it a showstopper to publication?

>
> 9.  Management Considerations
>
>     The management of LFA and remote LFA is the subject of ongoing work
>     withing the IETF[I-D.ietf-rtgwg-lfa-manageability] to which the
>     reader is referred.  In contrast to this text which recommends that
>     LFAs be preferred over remote LFAs,
>     [I-D.ietf-rtgwg-lfa-manageability] notes that there may be reason to
>     use remote LFAs even if ordinary LFAs are available.  This requires
>     further study.
>     
>     [SLI] I would remove "This requires further study.", as the problem is a true one, already proved, and there is already some implementations.
>     What would be the impact of always running rLFA ? I don't really see a reason to not do it by default.
SB> Until I-D.ietf-rtgwg-lfa-manageability is an RFC it is under
study in the IETF. The impact of always using rLFA is that you may
need more TLDP sessions, and depending on the implementation
you may need to use a longer path in the forwarder.
>     Computation is not a big deal and people who don't want remote LFA can choose to not activate it on a specific interface or node.
>     I don't want to see a "non good behavior" mentionned in the draft, just because one code is already running as you specified ... it may not be the good approach.
SB> This has nothing to do with existing implementations.
SB> It was the first approach proposed 13 years ago and is inherited
SB> from that early work.
>     I would propose to change your behavior and say always compute rLFA, and then tie break between all alternates.
SB> I think that the LFA rLFA choice is a local matter

SB> I have changed the text to

The management of LFA and remote LFA is the subject of ongoing work 
withing the IETF
[I-D.ietf-rtgwg-lfa-manageability] to which the reader is referred. 
Management considerations
may lead to a preference for the use of a remote LFA over an available 
LFA. This preference
is a matter for the network operator, and not a matter of protocol 
correctness.

- Stewart

---

From: Chris Bowers <[email-masked]>
Date: Mon, 4 Nov 2013 21:54:03 +0000

Following up on an item discussed in the meeting.  We agreed that the paragraph in section 4.2.2 (see below) that describes extended P-space in terms of (local)LFA should be removed because this alternative description may confuse the reader more than it enlightens.

Chris

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, November 01, 2013 9:46 AM
To: [email-masked]; [email-masked]
Subject: Re: candidate-draft-ietf-rtgwg-remote-lfa-03.txt

-----------------
Snip
-----------------

4.2.2.  Extended P-space

  I would propose :