[spring] Conflict resolution - a plea for simplicity
Stewart Bryant <stewart.bryant@gmail.com> Fri, 02 December 2016 17:55 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B7F129810; Fri, 2 Dec 2016 09:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ1l74UNZDZt; Fri, 2 Dec 2016 09:55:08 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E7D129DF1; Fri, 2 Dec 2016 09:54:54 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id g23so24140061wme.1; Fri, 02 Dec 2016 09:54:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=qSxbRmnXD1Yy3WSmwITd8XWASHLaJndPhO0juP2yt+I=; b=hMbsAyJLpqg4gA5MqvKPRPLkjAyaiuk0yDZoen5fvQusB4uztQlIC7+8NwIL8fSmfE W9QMXPQvSKXfJ+7xU+YcOTfiEc9TDZ8VdpGxy8FX5+ogONi9oDo0ninpFRu7rcl/x8/z FMUAXB8cpGtVPs4D6Dn0jhrz106GPUya7fH01005oWopPb9Hf3fNawxawT5GqM2sR0u2 0lhb2203/S8Tk7MUOr9ywGO4mh6ixy4Il4XJF9NjsYjJx4NpgqGWON8Tzj1OoiyyGh9a sJLH8QyH6wJ48aVgsbPEEsIbcoc2aV+fLpFt9krDN56E+uuK4JTrfhzvgMR3gXjJK4kZ KQeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=qSxbRmnXD1Yy3WSmwITd8XWASHLaJndPhO0juP2yt+I=; b=FykbX+NePH0h9t5tEBy6At5I52B1h1kzsg9v/JNYplQvprRdZaVaijcCbJLXPLoJAi lQuxXThR9bnWgQUiZGAxWP41+uiS+eR/ZWD8Z8gVYN+ZgDuJLGAq0YBbCydXu+OmUxWr gNJ/v6vGGxvKos0dPYifd39HWSvz8l6e/0Kfxqm1m5cwdiTr5SMbB00gq+VvbslL9BB/ c23GvU/+jOymSTnNnCdsUbQ329HkaxIzV7A0RKWav3+kV0PrqzheysFmsb3KB7iHbm1j wrK455NQDj+KME4b3a3RdNiUc69GIjbPHNmRS2kJsYbPtPEH/Nec86K/cWNmJZggR6s6 nYlw==
X-Gm-Message-State: AKaTC00mK+NI/7H3+GLN7ATxRcxTbVJN3+G6tSccmBEm+GlO58elKI6gtFakczYnOMVX8w==
X-Received: by 10.28.168.70 with SMTP id r67mr3890821wme.19.1480701292438; Fri, 02 Dec 2016 09:54:52 -0800 (PST)
Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id gk6sm6655873wjc.46.2016.12.02.09.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 09:54:51 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
To: "spring@ietf.org" <spring@ietf.org>, draft-ietf-spring-conflict-resolution@ietf.org
Message-ID: <ca931d36-8be4-6578-0b10-91acc8428d0e@gmail.com>
Date: Fri, 02 Dec 2016 17:54:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/G2myQnBr4DBlBpQV6mmQ7U_-DvE>
Subject: [spring] Conflict resolution - a plea for simplicity
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:55:10 -0000
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
- Re: [spring] Conflict resolution - a plea for sim… Stefano Previdi (sprevidi)
- [spring] Conflict resolution - a plea for simplic… Stewart Bryant
- Re: [spring] Conflict resolution - a plea for sim… Stewart Bryant
- Re: [spring] Conflict resolution - a plea for sim… Les Ginsberg (ginsberg)
- Re: [spring] Conflict resolution - a plea for sim… Stefano Previdi (sprevidi)
- Re: [spring] Conflict resolution - a plea for sim… bruno.decraene