Re: [OSPF] OSPF WG Minutes from IETF 95

"Acee Lindem (acee)" <> Fri, 15 April 2016 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70C8412E67B for <>; Fri, 15 Apr 2016 02:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B_F9-jeAL9vD for <>; Fri, 15 Apr 2016 02:51:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E13CE12E5C0 for <>; Fri, 15 Apr 2016 02:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4024; q=dns/txt; s=iport; t=1460713885; x=1461923485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dn+tcphC388lkr8qhh+w7ZLN8OvoEsTPbAONOmEzRDY=; b=c3m/NqRtIciSsuKjZTvSbatx6GCuxjRqOoABBjfuSSO4eP4P7WWPFjXZ KqZ98eBT0unFOo/Ohygth/zyPJuhwGYp4zswUvKlzmg5yhC6f0W8FRjVl qKrRwXcgH8k104Yvkf+vDT1PCtp2vJU86cbPlsdP7ZWgBFMpZSgGF5o/1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgCouBBX/4cNJK1egziBUAa4G4IPA?= =?us-ascii?q?Q2BcYYOAhyBITgUAQEBAQEBAWUnhEEBAQEDASMRRRACAQgYAgImAgICMBUQAgQ?= =?us-ascii?q?OBYghCK9zkhEBAQEBAQEBAQIBAQEBAQEBAQEXfIhugQKHP4JWBZMdhG8Bjg2PE?= =?us-ascii?q?Y8oAR4BAUKBf4FpbIhIfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,486,1454976000"; d="scan'208";a="259974822"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2016 09:51:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3F9pMW2024946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2016 09:51:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Apr 2016 05:51:23 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Fri, 15 Apr 2016 05:51:23 -0400
From: "Acee Lindem (acee)" <>
To: Paul Jakma <>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAIAAlAqA///jKQCAAVbTgIAA+ZOA
Date: Fri, 15 Apr 2016 09:51:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Fri, 15 Apr 2016 09:51:27 -0000

On 4/14/16, 10:58 AM, "Paul Jakma" <> wrote:

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

Using 0xfffe, in itself, will not cause backward compatibility problems.
However, you’ll still have backward compatibility issues as long as the
interpretation of 0xffff varies between router in the OSPF routing domain.
In reading the rest of this E-mail, I believe this is well understood.

>> 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.
>   0xfffe).
>   * 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

This sounds like a good plan.


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