Re: [RTG-DIR] RtgDir review: draft-ietf-spring-resiliency-use-cases-08

["Stefano Previdi (sprevidi)" <[e-mail]>]

Hi Stephane, Lou,

sorry, I missed that comment (in fact I did get it but forgot to address it).

I will add the necessary text and will submit a new version asap.

s.


> On May 4, 2017, at 9:50 AM, [e-mail] wrote:
> 
> Hi Stefano,
> 
> Speaking as doc Shepherd, I do not see in the V09, how you are addressing Lou's point about 1:1 and 1+1 protection in the Section 2.
> I think it make sense to add a simple explicit statement that  SPRING should support both approach. It is partially addressed by " The two paths may be used concurrently or as a primary and backup
>   path where the secondary path is used when the primary failed." 
> But the "concurrently" word is IMO ambiguous as it could mean 1+1 scheme or ECMP like behavior.
> 
> Brgds,
> 
> 
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[e-mail]] 
> Sent: Friday, April 28, 2017 12:54
> To: Lou Berger
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: RtgDir review: draft-ietf-spring-resiliency-use-cases-08
> 
> Hi Lou,
> 
> thanks for the comment. I integrated them in the new version I’ll submit asap.
> 
> Thanks.
> s.
> 
> 
>> On Apr 24, 2017, at 6:15 PM, Lou Berger <[e-mail]> wrote:
>> 
>> Hello,
>> 
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related 
>> drafts as they pass through IETF last call and IESG review, and 
>> sometimes on special request. The purpose of the review is to provide 
>> assistance to the Routing ADs. For more information about the Routing 
>> Directorate, please see 
>> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> 
>> Although these comments are primarily for the use of the Routing ADs, 
>> it would be helpful if you could consider them along with any other 
>> IETF Last Call comments that you receive, and strive to resolve them 
>> through discussion or by updating the draft.
>> 
>> Document: draft-ietf-spring-resiliency-use-cases-08
>> Reviewer: Lou Berger
>> Review Date: April 24
>> Intended Status: Informational
>> 
>> Summary:
>> 
>>   I have some minor comments about this document that I think would 
>> be good, but not necessary, to be resolved before publication.
>> 
>> Comments:
>> 
>> This document is concise and clear.  I only have minor/nit level 
>> issues that could be addressed before publication, but I don't think 
>> it critical as the document is being published as Informational.
>> 
>> Major Issues:
>> 
>> 	No major issues found.
>> 
>> Minor Issues:
>> 
>> - Section 2 mentions reversion, while sections 3 and 4 do not.
>> This leaves reversion requirements open to interpretation.
>> I suggest explicitly stating if reversion is a required  option or 
>> not in sections 3 and 4 as well.
>> 
>> - Section 2 mentions 1:1 style path protection.  Past/other work  on 
>> protection also allowed for / uses 1+1 style protection.  Is
>> 1+1 intentionally omitted? If not, I suggest allowing for it.
>> 
>> Nits:
>> 
>>> referred to as local protection techniques or Fast Reroute  
>>> techniques.
>> 
>> References should be provided for each technique.
>> 
>>>  It is essential that the primary and backup path benefit from an end-
>>>  to-end liveness monitoring/verification.  The method and mechanisms
>>>  that provide such liveness check are outside the scope of this
>>>  document.
>> 
>> Given the importance of liveness monitoring, I think it would be worth 
>> mentioned an example of such.
>> 
>> That's it!
>> Lou
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>