Subject: Re: WGLC for draft-ietf-rtgwg-remote-lfa

From: Stewart Bryant <[email-masked]>
Date: Mon, 12 May 2014 23:12:21 +0100

I am in the process of working through the comments received.

I have started with Alia's comments, which I have addressed as indicated
below.

I will post this as version -05. I will incorporate the other comments and
comments on the changes made in -05 in -06.

On 06/12/2013 23:03, Alia Atlas wrote:
> I've given this draft a thorough reading (except for commenting on the 
> cost-based algorithm that Pushpasis already gave feedback on).
>
> I have two major concerns.  First, I see no discussion at all about 
> how multipoint interfaces are handled.  Nothing indicates that they 
> are out of scope for protection nor does the discussion describe how 
> to handle avoiding the pseudo-nodes or related computation.
This is clarified in the Abstract, the ending of the Introduction and 
with some additional text in Section 4.3.

> Second, as a standards-track document, I see almost no description of 
> what MUST or even SHOULD be implemented.  What would conformance mean?
Please look version -05 and let us know if this is now addressed.
If not, please indicate what we need to address.
>
> Here are my detailed comments - in going through the draft order, not 
> by priority.
>
> 0)Sec 2: Can you add a paragraph describing the extended-P space and
> Q-space for the example in Figure 2?  It's fine to have the
> definitions, but it is jarring to run into Q-space in Sec 4 without
> any other reference.  For instance, just adding:
>
> "In [Figure 1], S can reach A, B, and C without going via E; these
> form S's extended P-space.  The routers that can reach E without going
> through S-E will be E's Q-space; these are D and C.  B has equal-cost
> paths via B-A-S-E and B-C-D-E and so may go through S-E.  The single
> node in both S's P-space and E's Q-space is C; thus node C is selected
> as the repair tunnel's end-point.  For more details on the reasoning
> behind these calculations, please see [Sec 4.2]"

Added

>
> 1) Sec 3, 2nd paragraph, 1 sentence:
>   "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."
>
> First, can you replace "assumed" with precalculated or the like?  This
> isn't an assumption - it is based on shortest-path forwarding and is
> carefully determined.
Done
>
> Second, "in the absence of multiple failures" should be "in the
> absence of a worse failure (e.g. node or SRLG) or multiple failures".
>
Done
> 2) Sec 3.1: For clarity, could you add a sentence indicating that the
> tunnel itself must also avoid going over the link S-E?
Done
>
> 3) Sec 3.2, 2nd paragraph:  "In order for S to obtain
>    the correct inner label it is necessary to establish a directed LDP
>    session[RFC5036] to the tunnel end point."
>
> Shouldn't that be a "targeted LDP session"?  I don't see directed at
> all in RFC5036 and am personally only familiar with them being called
> targeted LDP sessions.
Done
>
> 4) Sec 3.2 3rd paragraph: "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 repair tunnel endpoint."
>
> Decapsulation can occur at the penultimate hop, if the repair tunnel
> endpoint so specifies.

The text now says ...the decapsulation is normally configured
to occur at the penultimate hop...

>
> 5) Sec 3.2 3rd paragraph: "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."
>
> Can you please put some justification as to why this will not be a
> problem in normal operation?  Is your assumption that the added delay
> before the network is fully repaired acceptable because failure
> analysis studies indicate the separation between failures is generally
> at least X seconds and the time to establish a TLDP session and
> exchange labels (how many) is no more than Y seconds (in a router that
> is also dealing with reconvergence of all protocols beyond the IGP)?
>
> The extra communication clearly adds some delay before protection is
> available and a blanket assertion that it doesn't matter is more
> marketing than engineering.
It now says

"The time to establish the TLDP session and acquire labels will limit the
speed at which a new tunnel can be put into service. This is not 
anticipated
to be a problem in normal operation since the managed introduction
and removal of links is relatively rare as is the incidence of failure in a
well managed network."

>
> 6) Given that this is a standards-track draft, is there a reason that
> a minimum-to-implement tunnel type isn't specified?  I don't see/know
> of any references for how a router can know if a remote router can
> decapsulate IP-in-IP at speed or support GRE or even support a tLDP
> session.
There will normally be a preferred IP tunnel type in a particular IP network
and I would assume that was the type preferred for this purpose as well.
If we specify GRE and the network prefers IP-IP we cause more problems
than we solve. It therefore seems best to leave the IP tunnel type to the
preference of the operator.

Section 7 discusses the LDP case.

>
> 7) Sec 4.1: This seems to be ignoring the protection of per-prefix
> LFA, which is a superset of "link LFA".  More critically, as you know,
> doing per-prefix LFA can allow the protection of multi-homed prefixes.
> Can you please update this section to indicate how and if remote LFA
> applies to multi-homed prefixes?  As written, it sounds like it does
> not.  It also sounds as if remote LFA is required even if there is a
> per-prefix LFA for all destinations going via S-E.
The text now says:

Tunneled repair paths (which may be calculated per-prefix) are only
required for links which do not have a link or per-prefix LFA.
>
> 8) Sec 4.2.1, 2nd paragraph: "We will proceed as follows: we will
> describe how to compute the set of routers which can be reached from S
> without traversing S-E."
>
> For clarity, can you change this to: "how to compute the set of
> routers which can be reached from S on the shortest-path tree without
> traversing S-E"?  That may help remove some of the confusion when you
> then define extended P-space - where clearly S can reach as well."
>
> Please make the same change in the first sentence of 4.2.1.1.
I have reworded section 4.2.1 and included this change.
>
> 9) Sec 4.2.1.1 <http://4.2.1.1>: First, can you explain why you remove 
> those nodes that
> are ECMP in the draft?  I assume it is because such nodes require a
> directed first hop to avoid accidentally going through S-E.
>
> Second, after describing "excising the sub-tree" - what about a quick
> clue such as: "For example, if an SPF computation stores at each node
> the next-hops to be used to reach that node from S, then one can
> simply add a node to P-space if none of its next-hops are S-E"

The text has been reworded. Please check it.
>
> 10) How are multi-point interfaces handled?  I see no discussion of
> that in Sec 4.2.1.1 or Sec 4.2.1.2.
I am not sure further text is required. Please explain the problem
you are concerned about.
>
> 11) In Sec 5, I am confused by the example and I believe it is because
> there are typos?
>
> "When a failure occurs on the link between PE1 and P2, PE1 does not
> have an LFA for traffic reachable via P1.  Similarly, by symmetry, if
> the link between PE2 and P1 fails, PE2 does not have an LFA for
> traffic reachable via P2."
>
> But PE2->P1 has a cost of 1000 and PE1's path to P1 isn't affected by
> the failure of the link PE1-P2...  Could you please correct or clarify?
Figure corrected.
>
> 12) Sec 6: Given that [I-D.bryant-ipfrr-tunnels] is expired and not
> intended for publication and this draft is heading towards RFC, is
> there a reason not to accurately and fully pull out the problem
> description into this draft?
I am in the process of sending this to the ISE with some de-conflict
notes in the introduction.

Given that text and the existence of the node-protecting draft I think
that pulling text into this draft will make this draft unbalanced WRT the
problem it addresses.

>
> 13) Sec 6: The same problems can occur with SRLG failures.  Can you
> please add a brief paragraph decribing how the different cases apply
> for SRLG failure?  Also, please expand on the analysis recommendation.
I have added a sentence which I think addresses the issue succinctly.
>
> 14) Sec 7, 2nd paragraph: reference is to "Section 2" instead of
> "Figure 2".
Done
>
> 15) Sec 8: please update the "date of this draft" to be an actual date
> - as the draft is revised and progresses, this would falsely imply
> more recent data than will be there.
Done
>
> 16) Sec 8: Can you please define what is meant by "protected
> destinations" and "guaranteed node-protected destinations"?  Is the
> first if a destination is protected from all sources against all link
> failures?  Is it something more limited such as PLR/dest pairs?
This is clarified in the text
>
> 17) Sec 8.4: typo - "saleability" should be "scaleability".
Done
>
> 18) Sec 8.4:  The end of this section
>
> "In the very few cases where P and Q spaces have an empty
> intersection, one could select the closest node in the Q space and
> signal an explicitly-routed RSVP TE LSP to that Q node.  A directed
> LDP session is then established with the selected Q node and the rest
> of the solution is identical to that described elsewhere in this
> document.  Alternatively the segment routing technology being defined
> in the IETF may be used to carry the traffic between non-collocated P
> and Q nodes [I-D.filsfils-rtgwg-segment-routing-use-cases],
> [I-D.filsfils-rtgwg-segment-routing],
> [I-D.gredler-rtgwg-igp-label-advertisement]."
>
> seems to be describing functionality that isn't fully specified or
> mentioned elsewhere in the draft and that doesn't fall within RTGWG's
> charter.  If we include explicit routing rather than hop-by-hop, we've
> known how to do that for years.  At a minimum, it'd be useful to put
> this paragraph in a section by itself that is "Potential Coverage
> Improvements Via Explicit Routing" or the like.

I have used the word "potential"

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 May 2014 13:52:55 +0100

On 04/12/2013 20:26, Pushpasis Sarkar wrote:
>
> Hi Stewart/Alvaro,
>
> It maybe a very late, but I wanted to point the following issue with 
> the algorithm/psuedocode text provided in section 4.3.
>
> /////////////////////////////////////////////////////////////////
>
> //
>
> // Calculate extended P-space
>
> //
>
> // Note the strictly less than operator is needed to
>
> // avoid ECMP issues.
>
> Compute_Extended_P_Space(fail_intf)
>
> foreach node y in network
>
> y.in_extended_P_space = false
>
> // Extend P-space to the P-spaces of all reachable
>
> // neighbours
>
> foreach interface intf in self
>
> *[Pushpasis] From definition of intf.remote_node, there maybe multiple 
> 'remote_node's for a given 'intf' (specially if the 'intf' is a LAN 
> intf. So there should be another 'foreach intf.remote_node in intf' 
> loop here in this algorithm text.*
>
Since we do not support repair of a next hop lan the text is now:
               if (intf != fail_intf)
                    foreach neighbor n in intf.remote_node
                        // Apply RFC5286 Inequality 1
                        if ( D_opt(n, y) <
                                D_opt(n,self) + D_opt)(self, y)
                            y.in_extended_P_space = true

> **
>
> 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 the nodes in Q-space
>
> //
>
> 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
>
> Compute_and_Store_Reverse_SPF(self)
>
> foreach node y in network
>
> *[Pushpasis] Again from definition of intf.remote_node, there maybe 
> multiple 'remote_node's for a given 'fail_intf' (specially if the 
> 'fail_intf' is a LAN intf. So there should be another 'foreach 
> intf.remote_node in intf' loop here in this algorithm text. Also there 
> is a question of which 'remote_node' will the below inequality be 
> evaluated on in this case. This needs to be clarified. *
>
No, we are not supporting repair of a LAN, so I don't think this change 
is needed.*

*
>
> **
>
>               if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
>
> 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()
>
> *[Pushpasis] The PQ-space is a function of the 'fail_intf'. One node 
> maybe PQ-node for one 'fail_intf' and still not be the PQ-node for 
> another 'fail_intf'. So the 'fail_intf' should be a input parameter 
> for this procedure. Also the flags in_extended_P_space and in_Q_space 
> for node y should be defined per 'fail_intf'.*
>
> 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
>
fail_intf was a parameter to Compute_Extended_P_Space(fail_intf) and 
Compute_Q_Space(fail_intf)

I have clarified this in the introduction:
This section describes a method of computing the remote LFA repair 
target *for a specific failed link* using a cost based algorithm.

Clearly we could add the additional for loop in, but we are writing a 
description to aid understanding not compilable code, so the simpler we 
make it the better.

Stewart

> The current text needs to be enhanced and clarified with more details 
> to achieve completeness in my opinion. Once again regret the late 
> response.
>
> Thanks
>
> -Pushpasis
>
> *From:*Alvaro Retana (aretana) [mailto:[email-masked]]
> *Sent:* Wednesday, December 04, 2013 7:06 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* WGLC for draft-ietf-rtgwg-remote-lfa
>
> Hi!
>
> After what I thought was a productive set of feedback and discussion 
> related to this draft, both in the mailing list as well as at the 
> meeting in Vancouver, I would like to start a Working Group Last Call. 
>  This call will close by EOD (pick your favorite time zone) on 
> December 19, 2013.
>
> http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa
>
> Please provide specific feedback as to why you support (or not) the 
> advancement of this draft.  Please avoid "+1"-type responses.
>
> Thanks!
>
> Alvaro.
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html