Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

"Naiming Shen (naiming)" <> Wed, 29 November 2017 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C11E120721; Wed, 29 Nov 2017 14:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 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, 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 hZRRrsYpmRTm; Wed, 29 Nov 2017 14:47:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B1BA120046; Wed, 29 Nov 2017 14:47:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4940; q=dns/txt; s=iport; t=1511995625; x=1513205225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4D28T9a/5HhjCTRefKQB23gv5fCFGLnk1FUUmGzdlMQ=; b=KR9PVuY4GG22QhfAKusb533QCO7C6qq9FA376xC+xPcKLdmJlgJ02zW/ VPFSjhUHJ5cQTb4gO9nq4GlVuksCc3r9qnqzuwfTZjRQPKK2sYVuA/cIf zrj+rsAmLGdwitUdrk76lOtMygj/x8/mqcOAa7gwPPp165EaAw0ObtdIh A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AAC0Nx9a/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4UEweDeIogjnGBVyaWdIIRChgLhRgCGoR7PxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUfAQEBAQIBAQEbBhE6CwUHBAIBCBEEAQEBAgIjAwICAiULFAEICAIED?= =?us-ascii?q?gWKGggQp0iCJ4plAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IyggmDPioLgne?= =?us-ascii?q?FRoJvMYIyBaJNAodyjRqTUYx5iRwCERkBgTkBHzmBUW8VOioBgX6EVXeIY4EUA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="37602165"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 22:47:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vATMl4XE000503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Nov 2017 22:47:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 16:47:04 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 16:47:04 -0600
From: "Naiming Shen (naiming)" <>
To: "Ketan Talaulikar (ketant)" <>
CC: Christian Hopps <>, "" <>, "" <>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
Thread-Index: AQHTXmMvIlsDCkaUj0W5jcon0L55haMrdnkAgAD5RwA=
Date: Wed, 29 Nov 2017 22:47:04 +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: <>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Nov 2017 22:47:08 -0000

Hi Ketan,

thanks for the support and comments. some clarification inline,

> On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <> wrote:
> Hello,
> I support this draft, however would like the following aspect/scenario clarified.
> Consider the scenario where both the neighbours on a p2p link initiate the reverse metric procedure (i.e. include the TLV in their hellos concurrently). How are implementations supposed to handle this? Normally the choice of metric conveyed via this TLV is based on a particular condition (which need not just be "overload") on the local router which requires the neighbour to use shift to using the reverse metric supplied. So when both neighbours initiate this process, it would be good to have the specification provide a deterministic behaviour since the reverse metric values provided may conflict in certain "non-overload" conditions. If both routers simply accept the value supplied by their neighbour, it may not achieve the original purpose/design of this triggering this mechanism?

When you say if both sides initiated this ‘reverse metric’, you implied
there is a timing issue with this procedure in the draft.

The value of this ‘metric offset’ (or whatever will be called) of this TLV,
is just a number. The draft does not say this number is equal to the
configured ‘metric’ value plus the received ‘reverse metrc’ value, that
would be non-deterministic and both sides would keep going up until it’s

Each side of IS-IS link decides if it needs to send a ‘reverse metric’ over the link,
either in link-overloading case, or other cases. It’s a static number, it does not
depend on the other side sending a ‘reverse metric’ or not. This both sides
sending a ‘reverse-metric’ over a link is equivalent to an operator provisions
new metric (say both plus 10 to the old metric) on both sides of the link at
the same time, there is no non-determinitic thing in this.

- Naiming

> Following options come to my mind:
> a) when this condition is detected, none of the routers actually apply the reverse metric procedure
> b) when this condition is detected, the router with higher/lower system-id value (or some such tiebreaker) wins and the other withdraws its reverse metric (until then (a) applies)
> c) some mechanism/rule that is based on the value of metric offset specified perhaps (made harder since the actual metric is not signalled but the offset) which determines the "winner" so the other withdraws their TLV.
> Since the mechanism is not specific to overload conditions (where this is not an issue), it may be necessary for the specification to clarify this behaviour to ensure interoperability.
> Thanks,
> Ketan
> -----Original Message-----
> From: Isis-wg [] On Behalf Of Christian Hopps
> Sent: 16 November 2017 04:13
> To:
> Cc:
> Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
> The authors have asked for and we are starting a WG Last Call on
> which will last an extended 3 weeks to allow for IETF100.
> Thanks,
> Chris.
> _______________________________________________
> Isis-wg mailing list
> _______________________________________________
> Isis-wg mailing list