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. Second, as a standards-track document, I see almost no description of what MUST or even SHOULD be implemented. What would conformance mean? 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]" 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. Second, "in the absence of multiple failures" should be "in the absence of a worse failure (e.g. node or SRLG) or multiple failures". 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? 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. 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. 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. 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. 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. 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. 9) Sec 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" 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. 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? 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? 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. 14) Sec 7, 2nd paragraph: reference is to "Section 2" instead of "Figure 2". 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. 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? 17) Sec 8.4: typo - "saleability" should be "scaleability". 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. On Wed, Dec 4, 2013 at 8:35 AM, Alvaro Retana (aretana) <[email protected]>wrote: > 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. > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
