Skip to main content

Early Review of draft-bashandy-rtgwg-segment-routing-uloop-00

Request Review of draft-bashandy-rtgwg-segment-routing-uloop
Requested revision No specific revision (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-06-15
Requested 2017-05-25
Requested by Min Ye
Authors Ahmed Bashandy , Clarence Filsfils , Stephane Litkowski , Bruno Decraene , Pierre Francois , Peter Psenak
I-D last updated 2017-06-13
Completed reviews Rtgdir Early review of -00 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Request Early review on draft-bashandy-rtgwg-segment-routing-uloop by Routing Area Directorate Assigned
Reviewed revision 00 (document currently at 16)
Result Not ready
Completed 2017-06-13
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.

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.

   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.


   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)


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