Hi, The comments from Stewart where placed in the link https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-uloop-00-rtgdir-early-bryant-2017-05-30/ instead of being sent to the maling list.
I have cut-and-pasted the review comments from the link above and put my reply inline. See "#Ahmed"
Ahmed -------- This is the review for this draft and replaces the one I incorrectly submitted a few days ago. I have submitted a third party IPR disclosure relative to this draft, there is clearly an overlap with the IPR disclosed against RFC5715, and SR. There may of course now be other IPR. #Ahmed IPR disclosure will be made Subject to resolving the above, we should adopt the draft since SR can clearly be used to provide two stage loop-free convergence. ====== This document provides a mechanism leveraging Segment Routing to ensure loop-freeness during the IGP reconvergence process following a link-state change event. SB> Whilst technically that is a completely correct statement many readers SB> will interpret that statement as the provision of link protection SB> when you provide this service for link and node failure and SB> presumable for metric change. #Ahmed I do not understand what is the concern here? We use Figure 1 to illustrate the mechanism. In this scenario, all the IGP link metrics are 1, excepted R3-R4 whose metric is 100. We consider the traffic from S to D. SB> There needs to be a note of the symmetry properties of the links. #Ahmed Agreed ========= Stage 2: After C elapses, R installs the normal post-convergence FIB entry for D, i.e. without any additional segments inserted that ensure the loop-free property. SB> The timers can usefully be advertised rather than configured SB> (draft-bryant-rtgwg-param-sync) #Ahmed We will change the text to indicate that "C" can be determined in a way that is out of scope of the draft ========== 5. Security Considerations The behavior described in this document is internal functionality to a router that result in the ability to explicitly steer traffic over the post convergence path after a remote topology change in a manner that guarantees loop freeness. As such no additional security risk is introduced by using the mechanisms proposed in this document. SB> I don't think that there are zero increased risks. For example SB> the extended convergence delay and the presence SB> of routers without this feature magnifies the impact SB> of a link flap attack #Ahmed Actually I think the comment is not accurate. The mechanisms proposed in this draft moves the traffic to the post convergence path faster, or worst case, at the same speed without using these mechanisms. So if the proposed mechanisms do not enhance security, they are not adding any more risk On 6/14/2017 1:56 AM, Jeff Tantsura wrote:
Guys, Please work on resolving Early review RTGDIR comments. https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-uloop-00-rtgdir-early-bryant-2017-05-30/ Thanks! Cheers, Jeff On 6/13/17, 13:36, "IETF Secretariat" <[email protected]> wrote: Hello, This is a notification from the ID list for Routing Area Working Group. Document: draft-bashandy-rtgwg-segment-routing-uloop, https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-uloop/ Change: Request for Early review by RTGDIR Completed: Not Ready. Reviewer: Stewart Bryant. Best regards, The Datatracker draft tracking service (for the IETF Secretariat)
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
