Hi Stewart, Thanks for your comments. As an individual contributor, please find some comments inlined. [Bruno]
> From: spring [mailto:[email protected]] 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 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
