Re: [OSPF] OSPF WG Minutes from IETF 95

"Alvaro Retana (aretana)" <> Thu, 14 April 2016 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E346012E1EC for <>; Thu, 14 Apr 2016 06:28:30 -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 5UnOMmGMXiOA for <>; Thu, 14 Apr 2016 06:28:25 -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 D144912DF64 for <>; Thu, 14 Apr 2016 06:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3072; q=dns/txt; s=iport; t=1460640504; x=1461850104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ufD/zVhJXgmDr4h8eVHFmitvFez2giIYWyX+biU5am4=; b=UpA5HJu3DzL/q+5uEKlzysmpha+vX2bostgRtlRIm/dNS5g1rXn8g9h7 tQRWxEt8LQRbGHU0Tk1i3GXxTpvpO57PjFYI5XJ0qifT27e/h2gBCd8sg jzyZbLZBwBuQkVBTJ5Op7KmAO/eyIueR2UUvFhjN52mDqXnrad4GXc8Ia Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuBgA9mg9X/5pdJa1egziBUAa4GoIdg?= =?us-ascii?q?XGGDgKBNDkTAQEBAQEBAWUnhEIBAQQ6PxACAQg2EDIlAgQBDQWIKcJKAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBFYYhhEuKFQEEkx2EbgGODIFnh3aFM48oASEBQINnb?= =?us-ascii?q?IhIfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="96410569"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 13:28:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3EDSNYt001297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 13:28:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:28:23 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 08:28:23 -0500
From: "Alvaro Retana (aretana)" <>
To: "Acee Lindem (acee)" <>, Paul Jakma <>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Date: Thu, 14 Apr 2016 13:28:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
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: Thu, 14 Apr 2016 13:28:31 -0000

On 4/13/16, 6:31 PM, "OSPF on behalf of Acee Lindem (acee)"
< on behalf of> wrote:




>>Sure, 4 reads the other way but "deployment considerations" . I'm not
>>saying how it must be read, just saying it is possible to read the
>>stronger language of 3 another way.
>>I'm not trying to argue, I'm trying to explain why we are here.
>One of the authors or myself will write an errata to clarify this

What do you have in mind?

I may be too close to the text myself to tell where we should change
something.  Even if we interpret the "should not" in Section 3 as if it
was "SHOULD NOT", it is still not a "MUST"...and the obvious reason the
link would be used is if there isn't another path.

There is one part which I think can be clarified (only including the

4.  Deployment Considerations
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit, while the routers
   of the second type will still use this path, which may result in a

I'm open to other suggestions.



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.

      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.

4.  Deployment Considerations

   When using MaxLinkMetric, some inconsistency may be seen if the
   network is constructed of routers that perform an intra-area Dijkstra
   calculation as specified in [RFC1247] (discarding link records in
   router-LSAs that have a MaxLinkMetric cost value) and routers that
   perform it as specified in [RFC1583] and higher (do not treat links
   with MaxLinkMetric cost as unreachable).  Note that this
   inconsistency will not lead to routing loops, because if there are
   some alternate paths in the network, both types of routers will agree
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path.

   On the other hand, clearing the R-bit will consistently result in the
   router not being used for transit.

   The use of MaxLinkMetric or the R-bit in a network depends on the
   objectives of the operator.  One of the possible considerations for
   selecting one or the other is in the desired behavior if the path
   through the stub router is the only one available.  Using
   MaxLinkMetric allows for that path to be used while the R-bit