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, stephane.litkow...@orange.com 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:sprev...@cisco.com] > Sent: Friday, April 28, 2017 12:54 > To: Lou Berger > Cc: rtg-...@ietf.org; rtg-...@ietf.org; > draft-ietf-spring-resiliency-use-cases....@ietf.org; spring@ietf.org > 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 <lber...@labn.net> 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. > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
