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
