Re: [OSPF] OSPF WG Minutes from IETF 95

Paul Jakma <> Thu, 14 April 2016 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A9E312E444 for <>; Thu, 14 Apr 2016 07:58:16 -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 nV2eva5EzuaA for <>; Thu, 14 Apr 2016 07:58:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 135C712E329 for <>; Thu, 14 Apr 2016 07:58:13 -0700 (PDT)
Received: by with SMTP id n3so130324827wmn.0 for <>; Thu, 14 Apr 2016 07:58: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=+2DXV5YGJVEJ1yLEjLjM/b8AIDFbvjWgp+px4vHss/c=; b=0yRtRtCspHU2bWQ8QLFMfCNTw9Q01i/53wxeaWkYHUm4oMI/kKtZV6hZpaRYOofl5h EWr0ByQ4lON7xT8ynAzcBwB5U8auoa+x9kaJJxN1q6m7Qf8AZGZfy/YlSpYc3+i1jd6i nq5F0wjeqBg/AzeRkIi8wAtHN/7exIbA80sSts7XtbVm9pBQeVU2il/sEAB7paZdMNsI ErltFty3tQMXCsxCXm7wc/zE/Cq+T8OmiHa6oBqmZiYNlaS5KKKlp/pzrrNCe+q/TA7R V0s4RIRQA6M6y5FguJkn6XHd7qYOS/vDfF7r3GcJIksH5zfRU+bHrxmIbEu/tj8pkip+ t00g==
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=+2DXV5YGJVEJ1yLEjLjM/b8AIDFbvjWgp+px4vHss/c=; b=GlI3L54qymnMpkc+DaaLPFogzyVCiu+pCGfcuSFQySsxD3AYlst2qxssBEEZDBOGRC 8rzrLbMQIT0czfTfswkwaqphllNnLfKPYSzS2ScYXKA3601yQhMXrbDLEdJKc6KhMvcb ZXv+Ek0bFVz03iIUFdPFmkDxBbb539qaBumHJf0eFnpZt/Y87JSISZ5YG40BwR0O3Vyz +SVI6StHH8K/fo2VQwiftI79XkJJ34qfX6z3kyhFVWr2UxRljuEJ/GWctjLBXu4JHovo 48sF7IGM3/jZ/xcQwljudNyoHj4bBrEUHgkcihuNe0KD+T3zdLCfEI7Ko3KIGajfdo91 DJmA==
X-Gm-Message-State: AOPr4FVNjm1HyOZN+jir+E/Nbyg+N0aYUBxNa8lwqXvpttmk09NTQj6SxBORR/NhJOkdyA==
X-Received: by with SMTP id x4mr16510476wjx.122.1460645891517; Thu, 14 Apr 2016 07:58:11 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v6sm33709711wmv.16.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 07:58:10 -0700 (PDT)
Date: Thu, 14 Apr 2016 15:58:09 +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: text/plain; charset=US-ASCII; format=flowed
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: Thu, 14 Apr 2016 14:58:16 -0000

On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:

> One of the authors or myself will write an errata to clarify this
> definition.

Great. :)

> But the OSPF stub router functionality is achieved using 0xffff, so 
> your proposal is NOT backward compatible.

Why not?

Any sufficiently large metric (relative to the cost of the longest path 
in the network) will induce the desired "transit is still fine" 
behaviour in the stub-router RFC.

It turns out the 0xffff metric was never intended to be special by that 
RFC - or we wouldn't be having this discussion. It _not_ intended to 
change SPF behaviour. So, how could using a lower value cause 
compatibility issues? ??

> The reality is that the standards WILL NOT change to match your 
> interpretation.

Well, not asking you to. ;)

I'm just saying Quagga has been shipping for years with "0xffff link 
metric means its SPF will not follow such a link out of a router when 
calculating the SPF tree" behaviour. The reason was provide the 
"absolutely no-transit" type behaviour (as "discouraged, but transit is 
still OK" behaviour is achievable with many other metrics).

I'm not arguing for anything, I'm just saying the existence of such 
implementations is a reality.

For Quagga, it seems the best way forward is:

- As/when H-bit clearly is going to be a standard, Quagga can use H-bit
   + 0xffff link metrics to signal "absolutely no transit", when the
   administrator desires that behaviour.

   * This will have the desired effect with all routers that recognise
     the H-bit, and all Quagga

- If the administrator wants "discourage, but transit still OK" then
   Quagga will just set some large, non-0xffff metric in the links (e.g.

   * This will have the desired effect with all routers, Quagga old and
     new, RFC2328, pre-1583, etc., without any issues (AFAIK).

That seems the best thing we can do.

It leaves other cases where things might not quite be consistent. For 
those there'll be an admin option to control the SPF-0xffff-transit 
behaviour between the longish-standing Quagga "no-transit" behaviour and 
1583/2328. That will probably have to default to the "no-transit" 
behaviour for a while longer, but in time hopefully flip it over to 

Paul Jakma	@pjakma	Key ID: 64A2FF6A
Given sufficient time, what you put off doing today will get done by itself.