IETF Logo Mail Archive

Re: [OSPF] OSPF WG Minutes from IETF 95

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 14 April 2016 13:10 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4512D61A for <ospf@ietfa.amsl.com>; Thu, 14 Apr 2016 06:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SE9ZAbWNjra for <ospf@ietfa.amsl.com>; Thu, 14 Apr 2016 06:10:47 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F19512D591 for <ospf@ietf.org>; Thu, 14 Apr 2016 06:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2034; q=dns/txt; s=iport; t=1460639447; x=1461849047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y5CwdAeyGScPuKdUPiO2vm11BfI837XxkwtNbUGUmOg=; b=WWA4zxw9AJEi0eyK64+3EfAA2r4O2cApidoI8rcUKzXrt5nSl+cVdri7 2nuSFcgurFdlvBIti5RkTpsJVDt0SNmKeruTBwKUL6TeDIDs9LYrnhDuG hDHokazFlAlsKSRLiC284D2AXXyCYzN0AqKDFW6P+TlVJGn7WAMMffYSz M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BnAgDOlQ9X/5RdJa1egziBUAa4GoIPAQ2BcYYOAoE0OBQBAQEBAQEBZSeEQgEBBDo/EAIBCDYQMiUCBA4FiCnCRwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLihUFkx2EbgGODI8QjygBHgEBQoNnbIhIfgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="261451943"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 13:10:46 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3EDAkki015315 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 13:10:46 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:10:45 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 08:10:46 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Paul Jakma <paul@jakma.org>
Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95
Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01J+FBA8AgAA2vgCAAw3sAIAAFVgAgABQ+oCAANjmAA==
Date: Thu, 14 Apr 2016 13:10:45 +0000
Message-ID: <D3350900.11ED73%aretana@cisco.com>
References: <D330445B.58C7B%acee@cisco.com> <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> <D3313626.58E6F%acee@cisco.com> <alpine.LFD.2.20.1604131455120.18471@stoner.jakma.org> <D333DB19.59F07%acee@cisco.com> <alpine.LFD.2.20.1604132106430.13056@stoner.jakma.org>
In-Reply-To: <alpine.LFD.2.20.1604132106430.13056@stoner.jakma.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4117771D662DBB46991A544D203E255C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/MC66_tl_ihduy2c4txygTTr1h08>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] OSPF WG Minutes from IETF 95
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 13:10:49 -0000

On 4/13/16, 4:14 PM, "OSPF on behalf of Paul Jakma" <ospf-bounces@ietf.org
on behalf of paul@jakma.org> wrote:

[Speaking as WG participant and author of rfc6987.]

Paul:

Hi!

You and I have had a similar conversation off-list...

...
>I may have misinterpreted RFC6987, sure.
>
>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...

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

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

Regards,

Alvaro.

v2.23.0 | Report a Bug | By Email