Re: [spring] Conflict resolution - a plea for simplicity

[bruno.decraene]

Hi Stewart,

Thanks for your comments.
As an individual contributor, please find some comments inlined. [Bruno]

> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant  > 
> Sent: Friday, December 02, 2016 6:55 PM
> 
 > 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.

[Bruno]
You are correct that the draft handles a case of network/node misconfiguration, 
and that we are mostly tossing a coin to select one of the conflicting entries.
However I'm not seeing cases that would lead to misdelivery, misrouting or 
induced congestion:
- we are facing a case were e.g. one SID have been affected to the two 
different Segment/IP prefix/FEC.
- Those SID are just a number, locally allocated by the Autonomous System. 
Nobody cares much whether a given FEC uses the index 53 or 42. However, what we 
do need is that all nodes use the same value for a given FEC. Hence the needs 
for a determinist rule. This is the purpose of this draft.

If you see such misrouting, could you please elaborate on this? e.g. with an 
example.

 > 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.
 
[Bruno] IMO that's the case for both strategy. cf 1rst comment.
 
 > 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.
 
[Bruno] IMO that's the case for both strategy. cf 1rst comment.
 
 > 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.
 
[Bruno] They may be useful truths, but they are a bit too general to me. Not 
sure they will really help when discussing trade-off. 
One may add the robustness principle (RFC 3117, 761), especially since we are 
not even discussing a protocol error.
 
 > 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.
 
[Bruno] good point. Thanks.
 
 > 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,

[Bruno] In an ideal world, there would be no configuration error and no bug. 
But unfortunately, I'm not living in this world, so this is not a valid 
hypothesis for me. Hence the need for this document, so that a consistent 
behavior is picked.
(Eventually, in a world with no human (involved), although even God seems to 
play dice with the universe :-) )

> 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.
 
[Bruno] It's not about truth, and we don't care whether a given segment is 
given a value/index of N or M. In case of conflict, we have a set of values 
advertised, and we need to pick one, deterministically, using a preference or 
tie-break mechanism. 
That does not seem very far, to me, from the use case described in our draft 
https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-00#section-5 where 
different nodes advertise different value in the IGP and all nodes need to 
select the same one, in a distributed way.
 
 > 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.
 
[Bruno] traffic and path is not affected, whether value 42 or 53 is selected 
for a given segment. What we do need is consistency across all nodes.

-- Bruno


 > - Stewart
 > 
 > 

Re: [spring] Conflict resolution - a plea for simplicity

[Stefano Previdi (sprevidi)]

> On Dec 5, 2016, at 12:19 AM, Stewart Bryant  wrote:
> 
> 
> 
> 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.


an “SR route” is nothing else than a route for which you have a label.

the value this label (or index) has is mostly irrelevant as long as all nodes 
consistently use the same.

This is how SR works. Please refer to the long email thread on this matter.

s.



> 
> 
>> 
>> 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  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

Re: [spring] Conflict resolution - a plea for simplicity

[Les Ginsberg (ginsberg)]

Stewart -

I also am happy to get more feedback.
Inline.

> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Sunday, December 04, 2016 3:19 PM
> To: Stefano Previdi (sprevidi)
> Cc: spring@ietf.org; draft-ietf-spring-conflict-resolut...@ietf.org
> Subject: Re: Conflict resolution - a plea for simplicity
> 
> 
> 
> 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.
> 
[Les:] The issue here isn't to go via an SR path or not. It is how to decide on 
what MPLS label to use when there is a conflict i.e. either the same prefix has 
been advertised with multiple SIDs or the same SID has been advertised for 
multiple prefixes. Clearly if not all nodes in the network make the same choice 
we cannot guarantee that forwarding will work correctly.

What the draft authors have advocated for from the beginning is simplicity. 
Since there is no way to know which of the conflicting advertisements is the 
intended one, the simplest thing to do is not use any of them. This likely 
means that traffic to all of the affected destinations will be dropped. But as 
anyone experienced in deployments knows, there are many ways to misconfigure a 
network - and it isn’t possible to guarantee traffic delivery in the face of 
misconfigurations. What is essential is to detect and report the 
misconfigurations so that corrective action can be taken. 

In the course of the last few months we received feedback that pushed in the 
direction of trying to maximize delivery of traffic by trying to minimize the 
advertisements which are ignored when conflicts are detected. It is, of course, 
still not possible to know whether the choice made is correct or will even 
result in maximizing traffic delivery. The winning entry might turn out to be 
for prefixes which do not cover any actual traffic. But the most significant 
aspect of trying to maximize the number of mapping entries that continue to be 
used in the face of conflicting configuration is the added complexity in 
implementing the agreed upon preference rule in an interoperable way. In this 
regard all the points you have made are - IMO - quite valid. And we therefore 
will be asking the WG to take another look at a simpler proposal.

   Les


> 
> >
> > 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 
> 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 

Re: [spring] Conflict resolution - a plea for simplicity

[Stewart Bryant]

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  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

Re: [spring] Conflict resolution - a plea for simplicity

[Stefano Previdi (sprevidi)]

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.

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.

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).

Thanks.
s.


> On Dec 2, 2016, at 6:54 PM, Stewart Bryant  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