Re: [OSPF] OSPF WG Minutes from IETF 95

Paul Jakma <> Thu, 14 April 2016 15:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB13A12E1F5 for <>; Thu, 14 Apr 2016 08:20:46 -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 R4VQ0jlzhyLn for <>; Thu, 14 Apr 2016 08:20:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B1F212D9D3 for <>; Thu, 14 Apr 2016 08:20:43 -0700 (PDT)
Received: by with SMTP id v188so225195382wme.1 for <>; Thu, 14 Apr 2016 08:20:43 -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=xHcv2/iXL18kuTQ3ps70VarmQEyLMHTk9JKVHx6NWUw=; b=Oc93VRcfXJtOnh9zbse2SFA9/mrqHMnBIuG2UDwGWjS5HQ1aPcc9KEACDuoj91V1Fb XIRjwpAzUQiybBEfJX8KlNIvJZmn02gIhOuPMG7gSYkIf5htCr09Ij9WKvpzj5jERTNe wzM3frhhDjUU7jRGAdo0Q2OvfV9F4zdyIcOzKl51UaUAuWAI7rQ4GXBdwSF15TUzf2Vh 5ff3uUdzGFEyKAgcHAaiAOOLZ7SysugylYpiv+dtLPhK0FklxeTWGvE399T513Cipvs1 JlC0xmrB3anaNGfI8muxx4UNqMNk/QpFKMh19tKQeWdhE3JYwPlNXMh2/gySnRd8Cleb DTDQ==
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=xHcv2/iXL18kuTQ3ps70VarmQEyLMHTk9JKVHx6NWUw=; b=lU73/qLoHGPA1qtwyODNZkKUTxqKwYEpwtQYifi8XU+Ff5sLR0y3BM3X0gbScE2+HM HYkKbTiEtkGxnrmfXrl48MIU1r9dblJ0+3imZZ5XMYM3MV5HEN6RwgJPpWOKIj/rFjGf AhqxdejReqn8NTPyH6QKRs3gyOw2wK3Wm0zSfJDe2vVySrPgx3q5RwoZrK/JsKEQhKRh el95aSJyCxbAHdIPsKGlxZSNh7zfgeHQbCci4ghitsGFbmtWdoUr+s0F61ysvlrS/mjO Q8JvnCUXJ1tVfiUtJVoOvx9mr+7EbdWH0Ua4m7KtuegIXESEerWRC5IJeM0irh0y06oX Jw8A==
X-Gm-Message-State: AOPr4FUbRPIumuF114PAGR2cmdae/4WHkcMIFolGRZr5ue7QJmuFAa5vrpV2uy7CW1i+Pw==
X-Received: by with SMTP id ew3mr16557238wjd.6.1460647241768; Thu, 14 Apr 2016 08:20:41 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j18sm33979330wmd.2.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 08:20:40 -0700 (PDT)
Date: Thu, 14 Apr 2016 16:20:39 +0100 (BST)
From: Paul Jakma <>
To: "Alvaro Retana (aretana)" <>
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 15:20:47 -0000

Hi Alvaro,

On Thu, 14 Apr 2016, Alvaro Retana (aretana) wrote:

> Paul:
> Hi!
> You and I have had a similar conversation off-list...

Indeed, thanks for your help there. ;)

>> However, it is a fact that the behaviour desired by RFC6987 can be 
>> universally achieved with metrics of 0xfffe or lower. That was true 
>> before any misinterpretation, and is still true now.

> Both MaxLinkMetric and 0xfffe are "very large numbers" (VLN), which 
> means that if we use 0xfffe, or any other VLN (including 
> MaxLinkMetric), then we should get "the same" behavior.

> I wrote ""the same"" because the result can vary depending on which 
> VLN a router in the network uses with respect to another router that 
> may also want to be a stub.  For example, given 2 paths to a 
> destination, if a router uses 0xfffe (or any other VLN which is not 
> MaxLinkMetric) it should become a stub.  However, if a router on the 
> second path decides to use MaxLinkMetric, then the first one (the one 
> using 0xfffe) will become transit.  We can obviously expand that 
> example to n number of links and n values of VLN and end up with a 
> wide variety of results -- which will not be deterministic unless we 
> know which VLN each router used in each case...


However, this can happen with consistent use of 0xffff too. If both are 
0xffff, then a 3rd party router can still choose /either/ to route via, 
or both. Etc.

So, whether a router will or will not be used for transit will depend on 
the network topology, when a "transit is still OK" approach is still 

Also, this does not take the original link-metric into account either, 
right? It could be that the links on the one path originally were 100 
the other 1000. Clearly, if both now go stub, you'd want 3rd parties to 
prefer the "originally 100" one, but that information is lost.

So, if this were a consideration, wouldn't it be better to do 
stub-router with a "Add X to existing cost of all the links" approach? 
Where X is larger than the largest path cost, but less than the 
difference to 0xffff?

> When we originally wrote rfc3137 (the precursor of rfc6987), we chose 
> MaxLinkMetric because it guarantees the stub behavior (no other VLN is 
> higher), unless an alternate path does not exist.  Clearly we took 
> advantage of how the metric is treated in the current OSPF 
> specification (starting with rfc1583).  If we has used 0xfffe (or any 
> other VLN) then the behavior wouldn't have been guaranteed (using the 
> current OSPF spec).

Ah, ok.

Though, you didn't want to guarantee a router wouldn't be used... and as 
above judging the cost of alternate paths gets tricky with... Anyway. ;)

>> 0xffff today will not universally be recognised as meaning "you can 
>> still calculate transit paths out of a router using that link". 
>> 0xfffe or below will.
>> That is the reality today.
> True, but only for pre-rfc1583 routers.

Well, Quagga has treated 0xffff links as infinite / strictly-no-transit 
out of a vertex for 9 years now.

Paul Jakma	@pjakma	Key ID: 64A2FF6A
"I don't think they could put him in a mental hospital.  On the other
hand, if he were already in, I don't think they'd let him out."