Re: [OSPF] OSPF WG Minutes from IETF 95

Paul Jakma <paul@jakma.org> Wed, 13 April 2016 14:08 UTC

Return-Path: <paul@jakma.org>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F5E12E2BB for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 07:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.20150623.gappssmtp.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 WIKqAlL4xAnJ for <ospf@ietfa.amsl.com>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7AD9712E294 for <ospf@ietf.org>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id u206so80324946wme.1 for <ospf@ietf.org>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=S02ETnbp2SsnPxU+egpfwlrj5DXMd9DK0Np8TleVIVY=; b=otBLn4SBDqoqASI6JhbqMU+RvmviiDvBTX2Vl6rQEW849kyVg3ELpi3QZt/DFoAb3c qPSQREuF9imlnvjTN2yYIv/Hv9K4Xxbe3ZSnpgPLoNdaLB3JYgud7Mf1+0RgvVI4tR/s EFMCy3xGPI8/3VYPH3vFIv+mc80txDysNN7P/R0N73xxUiA1FieRQxZBITVFovOWm+PH HH+h39qjaVvzlEs+7N//2Nm8KmTTDJzmNfIMRqJpWfF60X83nuDJEMdT2lRxgBiLqGDL jxE4bG98adVdg+/xW4kkrKKrIldEzAt7oIW3UxqbwVK8eHx/OKagIcBonktQV9RH36Ts mDcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=S02ETnbp2SsnPxU+egpfwlrj5DXMd9DK0Np8TleVIVY=; b=LsK6djDh7OnhVSJH2dommd8zAHYZkHQJJcVsw9pq5Vr+0j7BsypgX8Y40uwh0dOUow D1BSf7aVa0iWTEImEVsAg3Xd7EvWB/faUxClhsb/D+zbiUBB7/UuZeBOsTo6EJrpNW7/ +sDD60GUDjureA3Os/5YJ/PlK0+D1PgFM1FZ5XiJnShFs/EBn6gQaB+vPyrpwQBvKL0H 1PKuPE3HnhbnQQjD4Jv8hCdnGVPkaFjJnkwNGxaZX2mQ0rR3i1FK16/PmaLM+AyMJ4UX msd5OB4j3XUrPOZd0NJhjdHsC5bfc1tJTo1n/0lS+B8MVLakstbrhZP37t5y3OnFX9XQ 39xA==
X-Gm-Message-State: AOPr4FXzJjccd2ZcopC6kIy89FicujkX9hEMUR9wLhUL98TIrZ46/itvk8xc0C14dHhfYA==
X-Received: by 10.195.13.135 with SMTP id ey7mr9961100wjd.161.1460556490764; Wed, 13 Apr 2016 07:08:10 -0700 (PDT)
Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id kj9sm38917575wjb.14.2016.04.13.07.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Apr 2016 07:08:10 -0700 (PDT)
Date: Wed, 13 Apr 2016 15:08:08 +0100 (BST)
From: Paul Jakma <paul@jakma.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
In-Reply-To: <D3313626.58E6F%acee@cisco.com>
Message-ID: <alpine.LFD.2.20.1604131455120.18471@stoner.jakma.org>
References: <D330445B.58C7B%acee@cisco.com> <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> <D3313626.58E6F%acee@cisco.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
X-Snooper: A life spent reading others private email is a sad and wasted one
X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone
X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-1471075816-739375895-1460556489=:18471"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/UfmteGGzzxxGiJRn4JLYIgdlQLg>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] OSPF WG Minutes from IETF 95
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2016 14:08:15 -0000

On Mon, 11 Apr 2016, Acee Lindem (acee) wrote:

> If in 2016 (22 years later), one particular implementation chooses to not
> comply to the specification, then there really isn’t anything the WG can
> do about it.

Part of the issue here was that the stub-router RFC features language 
that is often used to indicate authoritative changes to behaviour:

"3.  Maximum Link Metric

     Section 2 refers to the cost of all non-stub links as MaxLinkMetric,
     which is a new fixed architectural value introduced in this
     document.

    MaxLinkMetric
       The metric value indicating that a router-LSA link (see Section 2)
       should not be used for transit traffic.  It is defined to be the
       16-bit binary value of all ones: 0xffff."

Note the "should not".

Given that just discouraging traffic but still allowing transit, doesn't 
require any special metric valie to be called out - any high metric will 
do, that's just normal behaviour of metrics; and given that having the 
means to be able to totally disallow transit is desirable (see R-bit in 
v3, and the H-bit)... It's then not at all impossible to think the above 
did intend to mean 0xffff to not allow transit.

> The draft 
> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ allows a 
> link to be used exclusively for non-transit traffic. Of course, if you 
> also didn’t want to use the link for any traffic you simply wouldn’t 
> advertise it.

That won't work, I think.

Other hosts won't have a backlink then, and won't be able to calculate a 
route to the host. The OSPF host may then be unreachable. That's 
qualitatively different from other hosts still being able to calculate a 
path to the host it self.

For the RFC6987 desired behaviour, any high metric other than 0xffff 
will universally work.

For "no transit, and I really mean it", Quagga will follow the H-bit as 
soon as it's clear it will be a standard.

regards,
-- 
Paul Jakma	paul@jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
Small is beautiful.
 		-- Schumacher's Dictum