Re: [Gen-art] Gen-ART Telechat review of draft-ietf-rtgwg-remote-lfa-10.txt

[Suresh Krishnan <[e-mail]>]

Hi Stewart,
   Thank you for the quick response. Your proposed changes work for me. 
One small comment inline.

On 01/07/2015 06:49 AM, Stewart Bryant wrote:
> Thank you for the review Suresh.
>
> On 07/01/2015 09:13, Jari Arkko wrote:
>> Thanks for your review, Suresh. I agree with your points. Authors, are
>> you taking this into account?
>>
>> Jari
>>
>> On 07 Jan 2015, at 08:10, Suresh Krishnan
>> <[e-mail]> wrote:
>>
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>>
>>> Please wait for direction from your document shepherd or AD before
>>> posting a new version of the draft.
>>>
>>> Document: draft-ietf-rtgwg-remote-lfa-10.txt
>>> Reviewer: Suresh Krishnan
>>> Review Date: 2015/01/06
>>> IESG Telechat date: 2015/01/08
>>>
>>> Summary: This draft is ready for publication as a Proposed Standard but
>>> I have some minor issues that the authors may wish to address.
>>>
>>> Section 4.2.1.1:
>>> This sentence is missing a verb (reach?)
>>>
>>> The exclusion of routers reachable via an ECMP that includes S-E
>>> prevents the forwarding subsystem from attempting to <MISSING VERB> a
>>> repair endpoint via the failed link S-E.
> We will fix.

OK.

>>>
>>> Section 4.3:
>>>
>>> The Compute_Neighbor_SPFs() function seems to be missing a check for
>>> verifying if the interface is not the failed interface. I think the
>>> following check should be added.
>>>
>>> if (intf != fail_intf)
> It is certainly harmless to do the computation, and in an implementation
> that runs all the SPFs and banks them it will be needed if you protect
> one than one interface. The rest of the code assumes that you have
> all SPFs available. So I am not sure whether it is more confusing
> to put it in or leave it out. I am also trying to get my head round
> whether there are any corner cases that need that information (ECMP
> is normally the optimization killer).
>
> My inclination is to leave out the if statement and allow the implementer
> to find the optimization rather than risk forgetting some subtly.

I am fine either way as long as the description and the code are not in 
conflict.

Thanks
Suresh