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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 28 November 2017 03:16 UTC

Return-Path: <acee@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E5D129353; Mon, 27 Nov 2017 19:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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, URIBL_BLOCKED=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 7SYFKiYAmrww; Mon, 27 Nov 2017 19:16:27 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408691201F2; Mon, 27 Nov 2017 19:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39491; q=dns/txt; s=iport; t=1511838987; x=1513048587; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dx6KwJh9OIwWZfPVC2YgadjfmXdNZxcj+Iv+xq4LOq0=; b=i1RV8UXf4hRjIe8vAjFoTroO74rsctcnko++ggymjn4zJlRbwOjRjQ7y M7nmnLZgj2VNKBHqD51IQjApYjM8kgNZ+BUx9DFn1DVt8jOBW+EBvA6ps ApUrLG4HeHt+Htk5jfx1rhMgEmUuaCkAU3eZtK+KBRZl+v7NhGROE86c0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADl0xxa/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuFBMHg3iKII8UgX2WbYIOAwoYAQqFGAIahFo/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEBAwEBGwYKQQsQAgEGAhEDAQEBIQEGAwICAiULFAkIAgQBD?= =?us-ascii?q?QWJPmQQiQ+da4IninoBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM6ggeDPQGDK4U?= =?us-ascii?q?qEgYQgl+CYwWRdocwiSACh3CNGoIWhgyLLIx2iRcCERkBgTkBHzkmgSpvFTmCK?= =?us-ascii?q?YRVd4kOgRQBAQE?=
X-IronPort-AV: E=Sophos; i="5.44,466,1505779200"; d="scan'208,217"; a="37168320"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 03:16:26 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAS3GPIr007160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Nov 2017 03:16:26 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 27 Nov 2017 22:16:25 -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; Mon, 27 Nov 2017 22:16:25 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Naiming Shen (naiming)" <naiming@cisco.com>
CC: Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
Thread-Index: AQHTXmMuMOokR1pbPUaPu1E7vkG+66MkNH4AgATyvID//8wGgIAAWYKA///k94A=
Date: Tue, 28 Nov 2017 03:16:25 +0000
Message-ID: <D6423C7B.DBCAD%acee@cisco.com>
References: <87375fp3hv.fsf@chopps.org> <D63E0C77.DB3C2%acee@cisco.com> <487DD301-14A0-4DE6-9AD2-367A4B9B0402@cisco.com> <D6420A98.DBA49%acee@cisco.com> <05bbc83ec6ea4c0db1c379c9f514e756@XCH-ALN-001.cisco.com>
In-Reply-To: <05bbc83ec6ea4c0db1c379c9f514e756@XCH-ALN-001.cisco.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_D6423C7BDBCADaceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/FdiroiKCYwk2B6qdJkbRetq1n2E>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2017 03:16:30 -0000

Hi Les,

I guess we know the origin of the term “metric-offset” ;^)

From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Date: Monday, November 27, 2017 at 6:53 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "Naiming Shen (naiming)" <naiming@cisco.com<mailto:naiming@cisco.com>>
Cc: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org>" <isis-wg@ietf.org<mailto:isis-wg@ietf.org>>, "isis-ads@ietf.org<mailto:isis-ads@ietf.org>" <isis-ads@ietf.org<mailto:isis-ads@ietf.org>>
Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Acee –

The IS-IS draft is more flexible in this regard than the OSPF equivalent (https://tools.ietf.org/html/draft-ietf-ospf-link-overload-10).

In the IS-IS draft the text states:

“The Metric Offset field contains a 24-bit unsigned integer of an IS-
   IS metric that a neighbor SHOULD add to the existing, configured
   "default metric" contained within its IS Neighbors TLV…”

This allows that the operator could choose to set the neighbor metric to something other than “max-metric-1”.


Contrast this with the OSPF Draft which states:

“The node that has the link to be taken out of service MUST set metric
   of the link to MaxLinkMetric (0xffff)…”

Why are you comparing this draft to OSPF Link Overload? If you know the metric value, you don’t need any metric field (as is the case for OSPF Link Overload).

The text in the IS-IS draft needs to remain as it is.

The argument for keeping the text as is is flawed. Using "metric” or “reverse metric” for the identifier of the field would simply align it with the identifier for the advertising TLV. In the context of a reverse metric (the advertised TLV), it is not a metric offset even though it is added to the existing metric in the SPF computation.

Thanks,
Acee

   Les


From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 27, 2017 3:33 PM
To: Naiming Shen (naiming) <naiming@cisco.com<mailto:naiming@cisco.com>>
Cc: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; isis-ads@ietf.org<mailto:isis-ads@ietf.org>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Naiming,

From: "Naiming Shen (naiming)" <naiming@cisco.com<mailto:naiming@cisco.com>>
Date: Monday, November 27, 2017 at 4:38 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org>" <isis-wg@ietf.org<mailto:isis-wg@ietf.org>>, "isis-ads@ietf.org<mailto:isis-ads@ietf.org>" <isis-ads@ietf.org<mailto:isis-ads@ietf.org>>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07


Hi Acee,

thanks for the comments. replies inline with <NS>…</NS>

On Nov 24, 2017, at 3:05 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:

Hi,

I support publication of the subject document. I do have comments.

  1. Why do you call the reverse-metricn field, “Metric Offset”? This
sounds like a remnant of some bad 20th century CLI….

<NS>
the draft used to have the field as just ‘Metric’, since version 06, we responded
to the comments:


Section 2

From the description what is being advertised in the new TLV is not a metric but a metric offset i.e. you want the receiving IS to add the advertised value to its existing configured metric. Identifying the metric field as "metric offset" would make this point more clearly.


which is a good point I think. do you think there is an alternative name we
can use in replacing the ‘offset’ here?
</NS>

How about just calling it the “Reverse Metric”?

Thanks,
Acee




  2. Please split the single sentence description immediately following
figure 1 into multiple sentences. Maybe just refer to “Elements of
Procedure” sections rather than one incomprehensible sentence.
  3. Pervasive editorial comment, the plural of acronyms is does NOT have
an apostrophe. For example, it is TLVs, not TLV’s.

<NS>
will change those.

thanks.
- Naiming
</NS>



Thanks,
Acee


On 11/15/17, 5:43 PM, "Isis-wg on behalf of Christian Hopps"
<isis-wg-bounces@ietf.org<mailto:isis-wg-bounces@ietf.org> on behalf of chopps@chopps.org<mailto:chopps@chopps.org>> wrote:



The authors have asked for and we are starting a WG Last Call on

https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/

which will last an extended 3 weeks to allow for IETF100.

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org<mailto:Isis-wg@ietf.org>
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org<mailto:Isis-wg@ietf.org>
https://www.ietf.org/mailman/listinfo/isis-wg