Re: [OSPF] OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

"Acee Lindem (acee)" <acee@cisco.com> Fri, 12 January 2018 14:40 UTC

Return-Path: <acee@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 800C712E884 for <ospf@ietfa.amsl.com>; Fri, 12 Jan 2018 06:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 iolXCvNyO19R for <ospf@ietfa.amsl.com>; Fri, 12 Jan 2018 06:40:17 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F612124319 for <ospf@ietf.org>; Fri, 12 Jan 2018 06:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24047; q=dns/txt; s=iport; t=1515768017; x=1516977617; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ExTlbKeOXa9g59YLP34FVf1BCKpNya04kXMM+BQb8tY=; b=Cyw6eK1IQcq+dn6Xxzt7hR/ftNuYeDI1kmpV1Pitf8F5k5p/G1+/QK5U BV2X+sY5Uq49q5cWe3g/vZOdpiZfffPcOEGwJ4sOHBvmd7uk2ruh0KLCB 0ipAmu8b7mdeR9XCe9gx2pk4IRRc4izTySCMhGriRbV7wD47VuameI0GE w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CEAgAlyFha/4QNJK1eGQEBAQEBAQEBAQEBAQcBAQEBAYJKd2Z0JweEAJkEggKXMYIWCoU7AhqEJ0AXAQEBAQEBAQEBayiFIwEBAQQjCkwQAgEIEQMBAQEoAwICAjAUCQgCBA4FiU9krxSCJ4o4AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYQ8ghWGboMvBIF9EhaCYYJlBYtcmAgClUmUEJZ4AhEZAYE7ASEDNIFQbxU9gioJgkscgWd4ix6BFwEBAQ
X-IronPort-AV: E=Sophos; i="5.46,349,1511827200"; d="scan'208,217"; a="55244716"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 14:40:16 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0CEeGpZ011734 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jan 2018 14:40:16 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 12 Jan 2018 09:40:16 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 12 Jan 2018 09:40:16 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>
CC: OSPF WG List <ospf@ietf.org>
Thread-Topic: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC
Thread-Index: AQHTibmtxi8oQ47WLkuxOaaTq6cQQKNvxUQwgACNtAA=
Date: Fri, 12 Jan 2018 14:40:16 +0000
Message-ID: <D67E3113.EAE17%acee@cisco.com>
References: <D67AE2BC.E9365%acee@cisco.com> <BN3PR05MB270656E8380A03A67CCD9593D5170@BN3PR05MB2706.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR05MB270656E8380A03A67CCD9593D5170@BN3PR05MB2706.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: multipart/alternative; boundary="_000_D67E3113EAE17aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/e7oEadXpxkCy8y22uRhdVtY0G34>
Subject: Re: [OSPF] OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 12 Jan 2018 14:40:19 -0000

Hi Shraddha,

From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Date: Friday, January 12, 2018 at 3:07 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

Acee,

Pls see inline..

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Wednesday, January 10, 2018 7:51 AM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

Hi Shraddha,

We noticed that RFC 5817 sets the TE Metric to 0xffffffff for graceful TE shutdown and the OSPF Link Overload draft uses MAX-TE-METRIC (0xfffffffe). Two Questions:


1.       MAX-TE-METRIC is being defined in the OSPF Link Overload draft – correct? It is not a reference from some other RFC or draft?

<Shraddha>Yes. This value is introduced in this draft.

Given all work on TE, I was inclined to search for this constant in other documents. I think it would be useful to precede the definition with “This document defines MAX-TE-METRIC as 0xffffffe.” to avoid any confusion.


The reason was that some implementation treat te-metric 0xffffffff as invalid value and do not setup paths through them. Using 0xffffffff-1 seemed like a safe option

I was not aware some TE implementations did this. We definitely want it to be used as the least preferred path in this state.

I know that pre-RFC 2383 (not going to look up where it was actually changed) defined 0xffffff as unreachable and this was later deprecated.


2.       Why not just use 0xffffffff like RFC 5817?

<Shraddha>We can if we have the Working Group Consensus.

I don’t feel strongly but would err on the conservative side if there are implementations that treat 0xffffffff as unusable.

Thanks,
Acee




Thanks,
Acee