On 04/12/2016 15:53, Stefano Previdi (sprevidi) wrote:
Stewart,
thanks for the feedback.
Just to give you an update, the work currently done in the context of the
conflict-resolution draft aimed to, indeed, limit/reduce the impact of a
misconfiguration in presence of conflicting prefix/sid mappings.
It is based on the concept that there’s no such “bad” or “wrong” prefix/sid
mapping as long as all nodes use the same.
This philosophy always seems incorrect to me.
If the operator planed for some traffic to go via an SR route, then must
have done it for a reason. That reason may have been to protect a
property of the service, or to protect other traffic from that service.
Either way, if it is intended to go via an SR path, it really should go
via that path and not via some other path that the network is guessing at.
However, while we came up with a very efficient scheme, complexity is also part
of the picture from an implementation, deployment, troubleshooting perspective.
Not to mention the fun we’re going to have in doing interoperability tests.
Right, so why not just do something really simple.
So, the authors have raised this concern a few times but apparently the only
feedback we got (so far) from the WG was more oriented on the efficiency of the
conflict-resolution algorithm, regardless the simplicity (which is fine by me
as long as it is well understood).
Les Ginsberg is about to propose a simplification of the algorithm in order to
(re)introduce the simplicity of the original proposal (or at least try to
improve simplicity in the current scheme).
OK, look forward to seeing it.
- S
Thanks.
s.
On Dec 2, 2016, at 6:54 PM, Stewart Bryant <stewart.bry...@gmail.com> wrote:
There was some discussion on the conflict resolution draft at IETF97
that got cut off with a request to discuss on the list.
As I understand the situation, we have a misconfiguration in the network,
and we are being encouraged to take an essentially aggressive strategy
of picking one of the configurations and assuming that must be right
in order to continue forwarding traffic. It seems to me that we are
tossing a coin here and whilst we could be sending traffic the
right way we could also be sending it the wrong way with bad
consequences in terms of misdelivery or inducing congestion.
The alternative strategy is to note the conflict and not believe either
router. This more conservative strategy seems the better approach for
a number of reasons:
1) Traffic will not be misdelivered, or use unintended parts of the network.
2) Traffic, was being routed via SR rather than simple shortest path
for a reason and so you should not try to guess the operators decision,
you should rigidly execute it.
3) It seems to me that the aggressive approach fails 7 of Ross Callons
Twelve truths (RFC1925). These were published on 1/April, but the real
joke is that they ARE useful truths, so forget about the date. 3,
4, *5*, *6*, 8, probably 10, certainly 12.
4) Finally there is the protocol 101 rule stating that the exception
path MUST be simple, because it is rarely executed and thus often
hosts most of the bugs.
Point 4 is particularly important. What we have in the draft is
complex and difficult to test on a live network, and yet it is
only there to take action when someone makes a mistake.
Exception code like this is usually the Cinderella in the
system, rushed in at the end of development and hardly tested.
It is usually by far the best approach to assert that the
misconfiguration should never happen, have a very simple test
do detect it and do something very simple by effective when
it is detected. Given that routing only works because
routers tell the truth, and clearly one or both of the routers
has breached that trust, the best approach is to trust neither.
What is unclear to me is what to do with the traffic, i.e. do
you degrade it to the base path, or do you drop it. I would think
that the latter is the more conservative, because presumably it
was put in the SR path for a reason, and so SHOULD be carried on
an SR path.
- Stewart
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
