Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 05 January 2018 02:26 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697E912D72F; Thu, 4 Jan 2018 18:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 Ls62-1PPSfWH; Thu, 4 Jan 2018 18:26:51 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203BC1271FD; Thu, 4 Jan 2018 18:26:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10830; q=dns/txt; s=iport; t=1515119211; x=1516328811; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=65Nvaj2RKnhxVL8OY9cgNi9V3FK6oBRmWUY+9BZkh+A=; b=H1fftpuRFK06IztfQ0w9gygMgZdk/8sGPOmkDoS7aXZaggOYbNz7Syrq nwtAIMeNRyir4eIRhYwtW9LB4v0XVGmKUZTtpwMAOzi5qMXNj2AoP6O4m MS7Kg5rmUVSV8KzyZ/H5Z09h7P3H+T+Sl87Hwm1M5MVM6JjW6MVIIjhMu E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAQBm4U5a/5pdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYJKdGZ0JweEAIokjwiCAZFZhVGCFQoYAQyFFgIahBo/GAEBAQEBAQEBAWsohSMBAQEBAgEBASEKQQsFCwIBCD8DAgICJQsUEQIEAQ0FCIlDXAgQsHaCJ4o9AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEE4ISgVaBaAGDLoMvAQGFBIJlBZlqiW4CiASNLJQOjTGJMwIRGQGBOwEfOYFPbxU9giqEV3gBh2KBFwEBAQ
X-IronPort-AV: E=Sophos; i="5.46,316,1511827200"; d="scan'208,217"; a="52504653"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2018 02:26:50 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w052Qons001737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jan 2018 02:26:50 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 4 Jan 2018 20:26:49 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Thu, 4 Jan 2018 20:26:49 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Joel Halpern <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "ospf@ietf.org" <ospf@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-ospf-link-overload.all@ietf.org" <draft-ietf-ospf-link-overload.all@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-ospf-link-overload-11
Thread-Index: AQHThbuRS0E8Ymcr2kaVACNqyw2GeaNkihcw
Date: Fri, 05 Jan 2018 02:26:49 +0000
Message-ID: <bc44e16c2bf94d34a92d10c3f64ae07e@XCH-ALN-001.cisco.com>
References: <151510872060.14779.1209340587073567227@ietfa.amsl.com> <D6742D72.E86AC%acee@cisco.com>
In-Reply-To: <D6742D72.E86AC%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.161.233]
Content-Type: multipart/alternative; boundary="_000_bc44e16c2bf94d34a92d10c3f64ae07eXCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/xU_unq6uzN6B2cjhtdkH3riezQA>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jan 2018 02:26:53 -0000

> >Minor issues:

> >    I understand the WG likes using the term "overload" for a link

> >being taken

> >    out of service.  I think people will learn what we mean.  I do wish

> >we had

> >    not chosen to misuse the words in this fashion.  This is much more a

> >    graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >    overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use cases - you aren't actually going to shutdown the link. What you are going to do is make a link the "link of last resort".

This seems a better choice.



The suggestion from Shraddha that this term was borrowed from IS-IS isn't accurate. "overload" in IS-IS has a very different meaning - it indicates a node either has an incomplete LSDB or (a la RFC 3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and this was added recently to support the (very useful) TE use case which was defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When this was done the term "link-overload" was cut and pasted from the OSPF draft. I think this should also be changed in the IS-IS draft.



   Les



> Thanks,

> Acee

> >

> >

> >

>

> _______________________________________________

> OSPF mailing list

> OSPF@ietf.org<mailto:OSPF@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf