Thanks a lot for the quick response.
See inline "#Ahmed2"
On 7/7/2017 5:39 AM, Stewart Bryant wrote:
Hi Ahmed
Trimming this to the issues we need to discuss.
======
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?
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.
#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.
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
OK
==========
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
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.
Best Regards
Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
