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

[Stewart Bryant <[e-mail]>]

I agree, they must be aligned, let me see what the best way to fix it is.

Stewart

On 07/01/2015 23:56, Suresh Krishnan wrote:
> 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
>
> .
>


-- 
For corporate legal information go to:

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