[+rtgwg mailing list] Adrian,
Thanks very much for working through the example. It was very interesting to see an understanding by someone who isn't as close to the problem-space and helped pick up on imprecisions and lack of clarity in the definitions. Not to speak for Stewart - whom I'm sure will be responding quite soon, but... On Mon, Dec 29, 2014 at 11:09 AM, Adrian Farrel <[email protected]> wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-rtgwg-remote-lfa-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm placing this Discuss because I found the description of the > algorithm in 4.2.1 and the worked example in Section 2 to be at odds > with the definitions of P-space, extended P-space, and Q-space. > > I have been able to make things work by messing with the algorithm and > keeping the current definitions. You could probably do it by keeping > the algorithm and messing with the definitions. > Yes - we want to keep the algorithm. In particular, the pseudo-code gets it write and the definitions are a little sloppy. Stewart clarified a bit around the extended P-space not including paths through the failed link in the text before I put it to the IESG. > My workings were as follows, based on the example in Section 2: > > > S---E > > / \ > > A D > > \ / > > B---C > > > > In Figure 1 S can reach A, B, and C without going via E; > > these form S's extended P-space. > > First, this should say "via S-E" and "extended P-space with respect to > S-E". > > But... > > Extended P-space > > The union of the P-space of the neighbours of a > > specific router with respect to the protected link > > (Noting that 4.2.1.2 changes this definition *significantly* by saying > that the neighbour at the far end of the failing link - i.e., E in this > case - must be excised from the list of neighbours whose P-spaces are > combined). > To be fair, the definition of P-space (below) includes that the paths can't transit the protected link (S-E in the example). I think that the definition needs to be updated to be "the neighbors of a specific router that are reachable without going via the protected link". When there's only a single link S-E, S has no direct way of forcing traffic to E so E's P-space can't be included. ...and... > > P-space P-space is the set of routers reachable from a > > specific router using the normal FIB, without any path > > (including equal cost path splits) transiting the > > protected link. > > Now, S's neighbours are A and E. > The P-space of A with respect to S-E is {B, C} > And the P-space of E with respect to S-E is {C, D} > So the extended P-Space of S with respect to S-E is {B, C, D} > > Something is broken! > Yes, can't include the P-space of E when the failed link is S-E and there's no way to reach E directly (one hop) from S. > {A, B, C} is not even the (not extended) P-space of S with respect to > S-E which is {A, B} since C is not in that set because of SEDC. > On the other hand {A, B, C} *is* the extended P-space of E wrt S-E. > Although, I would observe that the pseudocode in 4.2.1 does derive > A, B, C as the extended P-space of S wrt S-E, but I think that is > because it has an entirely different definition of an extended P-space. > ?? Because it omits E? Do you see anything else different that needs to be better clarified? > Now... > > 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. > ...so the Q-space of S wrt S-E is {A, B} since CDES. > And, for the record, the Q-space or E wrt S-E is {C, D} > > Now, to compound the confusion, the example determines the PQ nodes for > S wrt S-E by taking the intersection of the extended P-space for S wrt > S-E and the Q-space of E wrt S-E. This is done notwithstanding the > definition... > > > PQ node A node which is a member of both the P-space and the > > Q-space. Where extended P-space is in use it is a > > node which is a member of both the extended P-space > > and the Q-space. In remote LFA this is used as the > > repair tunnel endpoint. > Yup - so clearly it means "of both the extended P-space of the PLR (S) and the Q-space of the far-end of the failed link (E)". Some improved definitions are definitely needed. > This definition gives the PQ nodes of S wrt SE as either > - the intersection of {A, B} and {A, B} if P-space is being discussed > or > - the intersection of {B, C, D} and {A, B} if extended P-space is being > used. > > So the correct tunnel end point for your example is B. > But it clearly doesn't work since traffic to E that is tunneled to B may > still be ECMP routed back along BAS. > > So I think in this whole example, you sit at S and you say "I want to > protect traffic to E". Then you work out the extended P-space of *E* wrt > S-E (which is {A, B, C}) and the Q-space of *E* wrt S-E (which is > {C, D}) giving you the correct PQ node for S to use to protect traffic > to E in the event of a failure of S-E as C. > Extended-P space is the space that the PLR S can send traffic to - what nodes can it reach without using the failed link. Q-space is what nodes can reach the far-end E of the failed-link S-E without using the failed link. Obviously the definitions need improvement. > It is simple! All you have to do is update the text to describe the > actual process and not the wrong one. Then the right result will pop > out :-) > > The replacement is > OLD > In Figure 1 S can reach A, B, and C without going via E; > these form S's extended P-space. > NEW > In Figure 1 S can reach A and B without going via S-E, and > D can reach B and C without going via S-E. So E's extended P-space > with respect to S-E is the nodes A, B, and C. > END > > > BUT, given all of this, are you sure that Section 4.2.1 is right? I'm > not. > Yes, not concerned about that. You are just high-lighting some imprecisions and lack of clarity in the definitions. > ------ > > Shouldn't the pseudocode in 4.3 be enclosed in code component macros to > match with the copyright TLP etc.? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This is not my area of expertise so please excuse the brevity of the > rest of this review. > > --- > > Please s/draft/document/ throughout (except the boilerplate and > filename) so that it can be published as an RFC (which is not a draft). > > --- > > Although it causes some pain with abbreviations and a little more care > in explanation, you need to put the Introduction as the first section in > the document. > > --- > > You are using RFC 5714 as a Normative Reference by making me go there > for the definition of terms. Please move it to the correct section. > > --- > > IMHO your definition of FIB is rather loose. Fortunately (?) "FIB" is > barely used in this document, so it might not be important, but if you > wanted to fix it: > - you are talking about IP packets in this document > Mostly MPLS actually... > - the actions are, I think, limited to forwarding actions > > --- > > This comment applies iff the resolution of the Discuss is not a complete > change to the terminology! > > I think definitions need to be tighter or omitted from this part of the > document. The definitions in 4.2.1 are more verbose and probably for > good reason. If you feel you need to retain these definitions early in > the document and can't lift the text from 4.2.1 then you need to address > the concerns below. > > P-space P-space is the set of routers reachable from a > specific router using the normal FIB, without any path > (including equal cost path splits) transiting the > protected link. > > "the protected link"? There is only one protected link? > > Since the example is worded as... > > For example, the P-space of S with respect to link > S-E, is the set of routers that S can reach without > using the protected link S-E. > > ...I think you need... > > P-space The P-space of a router with respect to a specific > protected link is the set of routers reachable from > the specific router using the normal FIB, without any > path (including equal cost path splits) transiting the > protected link. > > Similarly, you need... > > Extended P-space > The union of the P-spaces of all of the neighbours of > a specific router with respect to a single specific > protected link (see Section 4.2.1.2). > > But note that 4.2.1.2 makes a significant change to this definition. > > Q-space The Q-space for a specific router with respect to a > specific protected link is the set of routers from > which the specific router can be reached without any > path (including equal cost path splits) transiting the > protected link. > > PQ node A PQ node is a node which is a member of both the > P-space and the Q-space for the same router and with > respect to the same protected link. > > Where extended P-space is being discussed, a PQ node > is a node which is a member of both the extended > P-space and the Q-space for the same router and with > respect to the same protected link. > > In remote LFA the repair tunnel endpoint is a PQ node. > > Throughout the text, however, the terms are used rather loosely. For > example, when discussing Figure 1 you say "S's extended P-space", but > this is really "S's extended P-space with respect to S-E". Someone > familiar with the work might say that it is obvious from the context > that we are discussing the link S-E, and it is, but the terminology > needs to be tight. > > --- > > There is some difficult terminology in Section 2 > > 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. > > Is it the link or the node that is protected (or the traffic)? Perhaps > this could be rewritten to be less ambiguous. > > --- > > Section 2 > > B > has equal-cost paths via B-A-S-E and B-C-D-E and so may go through > S-E. > > I don't think B is going anywhere. Maybe... > > B > has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E > through S-E. > > --- > > Section 2 > > 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. > > But it would still benefit from a citation or a forward reference to > section 7. > > --- > > I enjoyed 3.2 > > relatively rare as is the incidence of failure in a well managed > network. > > So, managing my network well is protection against back-hoes. Nice. > LOL - the argument is about the set-up time to be protected again and what is the interval between failures. The editors and WG have decided that this trade-off is acceptable - but I'd also prefer to see it more clearly articulated. > --- > > In 3.2 > > Multiple > repairs MAY share a tunnel end point. > > 1. s/repairs/repair tunnels/ > 2. s/MAY/may/ since this is not an implementation or operational choice, > but a fact of life. > > --- > > In 4.2 you have truncated... > > The repair tunnel endpoint needs to be a node in the network > reachable from S without traversing S-E. > > ...and... > > o The repair tunneled point MUST be reachable from the tunnel source > without traversing the failed link; and > > You mean "reachable using the normal FIB" I think. > Not quite because if the repair tunnel endpoint is in the extended P-space and not the P-space, then S has to force the first hop rather than send it via the normal FIB. --- > > Section 4.3 > > 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. > > "mostly"? > > "reachability graphs"? Were they? Or were they reachability sets? > > --- > > Your pseducode in 4.3 invokes an unresolved (and undescribed) function > Compute_Forward_SPF(). > > Actually, I think this is a bogus line that can be deleted. > > --- > > 4.3 has > > if ( D_opt(n, y) < > D_opt(n,self) + D_opt)(self, y) > > Surely this is > > if ( D_opt(n, y) < > D_opt(n,self) + D_opt(self, y) ) > > --- > > I think the introduction of "pseudonode" in 4.3 may be a little without > context. > > --- > > Section 7 > If for any reason the TLDP session cannot > not be established > > s/cannot not/cannot/ > > --- > > I think [RFC5424] and [RFC3411] are pretty poor references to give in > section 7. You appear to be saying that an implementation that cannot > establish a TLDP session should write a MIB module, standardise it, and > then report an error. > > Can't you find an existing LDP MIB module that reports Session-up > failures? > > Or maybe just delete "using any well known mechanism such as Syslog > [RFC5424] or SNMP [RFC3411]." > > --- > > Why is the discussion of microloops on network re-converges considered > to be a management consideration (by inclusion in Section 9). Surely it > is a deployment or operational consideration. > I wanted that text somewhere in the doc. Adding an operational considerations section to put it in would be fine. > --- > > I think you can strengthen the security considerations. You have: > > To prevent their use as an attack vector IP repair tunnel endpoints > (where used) SHOULD be assigned from a set of addresses that are not > reachable from outside the routing domain. > > 1. "To prevent their use" is surely consistent with a "MUST". > The fact that you want to say "SHOULD" means that you need to turn > the text around... > > IP repair tunnel endpoints (where used) SHOULD be assigned from a set > of addresses that are not reachable from outside the routing domain. > This would prevent their use as an attack vector. > > 2. You can add a note about what traffic can be placed into a repair > tunnel. You already have this earlier in the document, and it is > worth restating. > > 3. I think you should also make note of whether the repair tunnel is > advertised by the routing protocol as an available link. > I agree on the comments otherwise. Regards, Alia
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
