Re: AD review comments on draft-ietf-rtgwg-remote-lfa-08

[Stewart Bryant <[e-mail]>]

On 12/12/2014 00:00, Alia Atlas wrote:

Alia thank you for your review.

Here are my responses and the changes make to -09
> Minor Comments:
>
> 1) In Sec 2, 3rd paragraph, in the sentence:
> "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."
> it should be "S's extended P-space"
Correct - changed
>
> 2) In Sec 2, it says: "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."
> This is obviously correct and good - but I think it would be very 
> useful to clarify that OAM traffic to test the rLFA may transit the 
> tunnel at any time.  Otherwise, the MUST NOT could cause some 
> confusion - depending on how one thinks about "normal traffic".
This now says:

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. Note that OAM traffic specifically to verify 
the viability of the repair MAY traverse the tunnel prior to a failure.

I used viability rather than for example "availability" to cover any 
form of OAM test (CC, CV, delay, jitter.....)

I toyed with saying "normal data traffic" and not adding the OAM 
sentence, but that would have allowed routing and network management 
traffic (other than OAM) which we also need to exclude.

>
> 3) In Sec 3:  I can't parse "Examples of worse failures are node 
> failures (see Section 6 ), and through the failure of a shared risk 
> link group (SRLG), the through the independent concurrent failure of 
> multiple links, and these are out of scope for this specification."
>
> I think you mean "Examples of worse failures are node failures (see 
> Section 6), the failure of a shared risk link group (SRLG), the 
> independent concurrent failures of multiple links; protecting against 
> such worse failures is out of scope for this specification."  I would 
> add in the failure of broadcast interfaces and NBMA interfaces for 
> completeness, even though that was mentioned in Sec 2.
This now says:

Examples of worse failures are node failures (see Section 6), the 
failure of a shared risk link group (SRLG), the independent concurrent 
failures of multiple links, broadcast or non-broadcast multi-access 
(NBMA) links [Section 2]; protecting against such worse failures is out 
of scope for this specification.

>
> 4) In Sec 4.2: "Provided both these requirements are met, packets 
> forwarded over the repair tunnel will reach their destination and will 
> not loop."  Please change to:
> "will not loop after the single link failure".  Of course, looping can 
> happen if a worse failure than protected against occurs - as with 
> LFA.  This could also be mitigated by requiring that the PQ node is 
> downstream of the PLR, as  is mentioned in Sec 4.2.2.
Correct

This now says:

Provided both these requirements are met, packets forwarded over the 
repair tunnel will reach their destination, and will not loop after a 
single link failure.
>
> 5) In Sec 4.2.1.2 <http://4.2.1.2>: "This may be calculated by 
> computing an SPT at each of S's neighbors (excluding E) and excising 
> the subtree reached via the path N->S->E."
> As described here, a node Y that is reached via N->S->A would be 
> considered to be in S's extended P-space.  I realize that one would 
> assume that Y would be in S's P-space anyway and thus it is safe to 
> not care about this edge case.  However, the ECMP considerations make 
> it more complex so please at a minimum add in the same caveat as in 
> Sec 4.2.1.2  "(including those routers which are members of an ECMP 
> that includes link S-E)" suitably modified.  In the cost-based version 
> in Compute_Extended_P_Space, this is handled by ignoring any potential 
> node from N whose shortest path goes back through S.  It'd be nice if 
> the two methods were consistent.
I have changed the text to:

This may be calculated by computing an SPT at each of S's neighbors 
(excluding E) and excising the subtree reached via the path N->S->E. 
Note this will excise those routers which are reachable through all 
ECMPs that includes link S-E.

I am not sure that this clarification is strictly needed since "removal 
of the subtree reached via the path N->S->E" would include "those 
routers which are members of any ECMP that includes link S-E".

Would it be less confusing if we changed "excising the subtree reached" 
to "excising the routers reached"?
>
> 6) In Sec 4.2.2: "As described in [RFC5286], always selecting a PQ 
> node that is downstream with respect to the repairing node, prevents 
> the formation of loops when the failure is worse than expected." 
>  Could you clarify that the PQ node is downstream with respect to the 
> repairing node and the destination - rather than the proxy destination 
> E?  I'm fairly certain that the latter wouldn't work (but don't have 
> an example topology created).  If you disagree, let me know and I'll 
> work on creating one.   This is the constraint that is expressed in 
> Apply_Downstream_Constraint().
I don't think there is a problem in practice since if PQ needed to be 
downstream to E WRT S, D_opt(PQ,E) < D_opt(S,E) would apply and in a 
unit cost network there would be no PQ nodes since we would need 
D_opt(PQ,E) < 1, i.e. a link metric from PQ to E of less than one. PQ 
nodes would be so rare that this would no be a practical solution.

I have changed the text to:

As described in [RFC5286], always selecting a PQ node that is downstream 
to the destination with respect to the repairing node, prevents the 
formation of loops when the failure is worse than expected. The use of 
downstream nodes reduces the repair coverage, and operators are advised 
to determine whether adequate coverage is achieved before enabling this 
selection feature.
>
> 7) In Sec 4.3: "The reader is referred to 
> [I-D.psarkar-rtgwg-rlfa-node-protection] for further information 
> on the use of RLFA for node repairs." Can you add "and broadcast or 
> NBMA link repairs"?   Do you feel that is accurate?
>
I cannot see any text on broadcast or NBMA in the draft which is now 
draft-ietf-rtgwg-rlfa-node-protection (updates in text)

I have made no text change on the substantive point.
> 8) In Sec 6: s/"When the failure is a node failure rather than a link 
> failure"/"When the failure is a node failure rather than a 
> point-to-point link failure"
Done
>
> 9) In Sec 6: "Alternatively one might choose to assume that the 
> probability of a node failure and microloops forming is sufficiently 
> rare that the case can be ignored."  Can you please clarify from 
> microloops to "microloops forming due to use of alternates"?  We know 
> that in cases where a rLFA is necessary, that neighbor isn't loop-free 
> and so regular microloops due to reconvergence will form.
>
It took a while to understand the comment but I think I know what you mean.

I have changed the text to:

Alternatively one might choose to assume that the probability of a node 
failure is sufficiently rare that the issue of looping RLFA repairs can 
be ignored.
> 10) In Sec 7: "In the absence of a protocol to learn the preferred IP 
> address for targeted LDP, an LSR should attempt a targeted LDP session 
> with the Router ID [RFC2328] [RFC5305] [RFC5340], unless it is 
> configured otherwise."  Can you please add in some text for how this 
> would work for IPv6?  I believe that there are current drafts 
> discussing carrying Routable IP addresses (e.g. 
> http://datatracker.ietf.org/doc/draft-ietf-ospf-routable-ip-address/ 
> ).  We know that there is interest in having IPv6 only networks with 
> MPLS - so it'd be good not to create new gaps.

It now says

In the absence of a protocol to learn the preferred IP address for targeted LDP, an LSR should attempt a targeted LDP session with the Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] [I-D.ietf-ospf-routable-ip-address"
], unless it is configured otherwise.

>
> 11) In Sec 8.4: "In an MPLS network, this is achieved without any 
> scaleability impact, as the tunnels to the PQ nodes are always present 
> as aproperty of an LDP-based deployment."  The targeted LDP sessions 
> don't have a scaleability impact?  That the repair tunnels don't need 
> to be specifically created as new tunnels, I agree with - but this 
> statement is overselling. Please make the technical point more clearly.
>
I have cut this back to

As shown in the table, remote LFA provides close to 100% prefix 
protection against link failure in 11 of the 14 topologies studied, and 
provides a significant improvement in two of the remaining three cases. 
Note that in an MPLS network the tunnels to the PQ nodes are always 
present as a property of an LDP-based deployment.

> 12) In Sec 9:  I feel like here is a good place at least mention the 
> issues with microloops from reconvergence.  Since reconvergence after 
> rLFA is going to result in a local microloop (depending on timing), at 
> least a reference to 
> https://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-03 with 
> a recommendation to consider it is important. Otherwise, the rLFA 
> repair happens and then traffic microloops and is lost.  The fact that 
> these local microloops occur with real impact much more with rLFA (or 
> any advanced FRR technique) is an important management consideration.
I have added the following new para:

When the network re-converges, microloops [RFC5715] may form due to 
transient inconsistencies in the router FIBs. If it is determined that 
microloops are a significant issue in the deployment, then a suitable 
loop free convergence methods such as one of those described in 
[RFC5715], [RFC6976] or  [I-D.litkowski-rtgwg-uloop-delay] should be 
implemented.

>
> 13) Sec 12:  Saying "To prevent their use as an attack vector the 
> repair tunnel endpoints SHOULD be assigned from a set of addresses 
> that are not reachable from outside the routing domain." is basically 
> empty words without more behind Sec 7 default of using Router IDs.  
> Can you find a reference that talks about a BCP for Router IDs not 
> being reachable addresses outside the routing domain? Can you describe 
> how to use the IGP extensions?
Router IDs are used for T-LDP and normal MPLS security applies.

Again with MPLS repair tunnels normal MPLS security applies.

The Section 12 reference was to IP tunnels in an IP rather than MPLS 
network. I have changed the text to:

The security considerations of [RFC 5286] also apply.

Targeted LDP sessions and MPLS tunnels are normal features of an MPLS 
network and their use in this application raises no additional security 
concerns.

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.

>
> Nits:
>
> a) In Sec 4.2.1.1 <http://4.2.1.1>: "The exclusion of routers 
> reachable via an ECMP that includes S-E prevents the forwarding 
> subsystem attempting to a repair endpoint via the failed link S-E."
> s/attempting to a repair/from attempting to use a repair
Done
>
> b) In Sec 10: "We propose "Remote LFA" as a natural second step." 
>  This is going to be an RFC - so rather than propose, try specify.
>
I have changed this to:
> The purpose of LFA FRR technology is to provide for a simple FRR 
> solution when such a solution is possible. The first step along this 
> simplicity approach was "local" LFA [RFC5286]. This specification of 
> "Remote LFA" is a natural second step.

Hopefully these resolutions are acceptable to all. If not please let me 
know.

New version at http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/

Diffs at 
http://www.ietf.org/rfcdiff?url1=draft-ietf-rtgwg-remote-lfa-08&difftype=--html&submit=Go!&url2=draft-ietf-rtgwg-remote-lfa-09

- Stewart