Subject: Response to Early review for draft-bashandy-rtgwg-segment-routing-uloop

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 06 Jul 2017 05:03:25 -0700

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-masked]> 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)
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 7 Jul 2017 13:39:16 +0100

Hi Ahmed

Trimming this to the issues we need to discuss.
> I do not understand what is the concern here?

Those that know the detail will understand that "link-state change event"
covers (multiple)link failure, node failure, and both increase and decrease
of link metrics. A lot of readers will not appreciate the range of events
that "link-state change event" encompasses, nor will they realize that
you can get looks when you get good news as well as bad news. My
suggestion is that you spell this out for the reader so the appreciate the
applicability of the RFC.

> way that is out of scope of the draft

OK

> 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

You may be correct, I need to think about the interactions between nodes 
that do and do not support this mechanism which is where the problem 
normally arises.

Something that I did not see was any comment on the need to abandon this 
if the failure was worse than expected.

Best Regards

Stewart

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Fri, 07 Jul 2017 10:48:28 -0700

Thanks a lot for the quick response.

See inline "#Ahmed2"

> applicability of the RFC.
#Ahmed2:
At this point in time, the mechanisms in this draft intend to cover all 
remote topology changes that may risk microloops. Hence there is no need 
to spell each one out. As we progress, we may decide to limit this draft 
to particular types of topology changes. At that time we will explicitly 
spell out such types.
> You may be correct, I need to think about the interactions between 
> nodes that do and do not support this mechanism which is where the 
> problem normally arises.
>
> Something that I did not see was any comment on the need to abandon 
> this if the failure was worse than expected.
#Ahmed2
The last statement is not related to security. It is an intuitive 
implementation detail that any reasonably skilled engineer will take 
care of. As with any feature, if an implementation chooses to implement 
some but not all of the mechanisms of the feature, then it is the 
responsibility of the implementer to make sure that the implementation 
gets applied as intended.