Re: [OSPF] OSPF WG Minutes from IETF 95

Paul Jakma <> Wed, 13 April 2016 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4F5E12E2BB for <>; Wed, 13 Apr 2016 07:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WIKqAlL4xAnJ for <>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AD9712E294 for <>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
Received: by with SMTP id u206so80324946wme.1 for <>; Wed, 13 Apr 2016 07:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id ey7mr9961100wjd.161.1460556490764; Wed, 13 Apr 2016 07:08:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id kj9sm38917575wjb.14.2016. (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 <>
To: "Acee Lindem (acee)" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
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: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] OSPF WG Minutes from IETF 95
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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

Paul Jakma	@pjakma	Key ID: 64A2FF6A
Small is beautiful.
 		-- Schumacher's Dictum