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

Shraddha Hegde <shraddha@juniper.net> Fri, 12 January 2018 02:51 UTC

Return-Path: <shraddha@juniper.net>
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 89AC412D72F; Thu, 11 Jan 2018 18:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 rhJdqtGwhjql; Thu, 11 Jan 2018 18:51:04 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E146126D45; Thu, 11 Jan 2018 18:51:04 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C2ndgm020067; Thu, 11 Jan 2018 18:51:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=mR4WVON3vaeAM+P/7565Xac6nbIP7pstRXv6ajeSrVc=; b=PxH/506XF5L7zANVTejH+Na32xnitMYXgsQnGt8Ist1luL0tdP6WbMsCHsi86uU2UkLr 7iNhVPOxKAT4/vkBoW4Z6/56HOsRSPk4CBNld6Df3pe9v1AGZisx8qSNKGB8sXFnOWZQ f21C9qmAH1xhzRd2++/aCX0/YrNyI4+pMVqW5ZM8b+0NznjsHR23gXBbOphXIZG/nFMV +GhdPKRmPKxeI76ARG4vtfB550Qt4x/F9NujBPbKK3Sd7qHGMAwiNIu9ImIVRkjBlWar p0hn9w3ol5c23BGz4c0AXJsbmieQrgLIa3YgHAWX4+9zGlPbqL7PARkgbeKRNXFYjGdK 9g==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) by mx0b-00273201.pphosted.com with ESMTP id 2fej4x8bmr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 18:51:00 -0800
Received: from BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) by BN6SPR00MB2470.namprd05.prod.outlook.com (10.173.26.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.428.9; Fri, 12 Jan 2018 02:50:58 +0000
Received: from BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) by BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) with mapi id 15.20.0407.000; Fri, 12 Jan 2018 02:50:58 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Bruno Decraene <bruno.decraene@orange.com>
CC: "Acee Lindem (acee)" <acee@cisco.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Joel Halpern <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "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: AQHThbQ7+8DgUutPmUiEFZ4xGB5kgqNka2SAgAAieoCAAATWgIAAF7IAgAANWQCAAIySgIAAMLZwgASLx4CAAD5KAIAACrCAgAVJVoA=
Date: Fri, 12 Jan 2018 02:50:58 +0000
Message-ID: <BN3PR05MB2706F5D5841EBF0DEA6ADE9AD5170@BN3PR05MB2706.namprd05.prod.outlook.com>
References: <151510872060.14779.1209340587073567227@ietfa.amsl.com> <D6742D72.E86AC%acee@cisco.com> <bc44e16c2bf94d34a92d10c3f64ae07e@XCH-ALN-001.cisco.com> <D6745005.E86F2%acee@cisco.com> <07098d41e11849d9a320061bb68aec0f@XCH-ALN-008.cisco.com> <cbdc429805b64c87a4f66cb3da1a49d2@XCH-ALN-001.cisco.com> <D674E4F9.E87E8%acee@cisco.com> <BN3PR05MB27061E9F6515017EF94E10DCD51C0@BN3PR05MB2706.namprd05.prod.outlook.com> <26758_1515418771_5A537493_26758_190_1_53C29892C857584299CBF5D05346208A4793F82A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CAEFuwkiy1Rdnba3jyEcYq_43Xyutm9S4mQHpuGe2UnHE11Twbw@mail.gmail.com> <59e6064165714b7f8ad0dad60e71f9bd@XCH-ALN-001.cisco.com>
In-Reply-To: <59e6064165714b7f8ad0dad60e71f9bd@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6SPR00MB2470; 7:oUQH3idNBnl9AKT0DLYuqRKZYxbk1FBjjPxhriP5vBO95f1sRmC4QFxCRMHJcteOHknMJ8vP9CCkzdo4VotMYRrbvgTiHT78oMXEf+qyZ9Qms3NCIe3s+iyEF2B2xQwgsVA0jdpOhT0i7Den03YNMb9UfECCvznSWXgWDB/cdgp64VECpbeimbxpDxZR52SZD+09U5bXIiigVSKoVJx6xT6+TgZxaFLNqC9kKAAOb+YnECT4TBFbcnK3svqkv38y
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dea6776e-9bf4-496b-4634-08d559674f2d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020075)(4652020)(5600026)(4604075)(3008032)(4534105)(4602075)(4627201)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:BN6SPR00MB2470;
x-ms-traffictypediagnostic: BN6SPR00MB2470:
x-microsoft-antispam-prvs: <BN6SPR00MB2470C4E4B72655C7C4F8C7CAD5170@BN6SPR00MB2470.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(138986009662008)(85827821059158)(100405760836317)(95692535739014)(18271650672692)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(944501138)(10201501046)(3002001)(6055026)(6041268)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN6SPR00MB2470; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:BN6SPR00MB2470;
x-forefront-prvs: 0550778858
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(366004)(396003)(39860400002)(69234005)(199004)(189003)(24454002)(6436002)(59450400001)(6506007)(76176011)(53546011)(106356001)(7736002)(77096006)(790700001)(7696005)(229853002)(74316002)(105586002)(8936002)(7416002)(102836004)(6246003)(8676002)(6116002)(39060400002)(68736007)(25786009)(3846002)(81166006)(81156014)(4326008)(55016002)(97736004)(6306002)(54896002)(53946003)(9686003)(53936002)(2950100002)(236005)(2906002)(86362001)(5660300001)(3660700001)(5890100001)(93886005)(3280700002)(66066001)(19609705001)(230783001)(606006)(14454004)(2900100001)(966005)(478600001)(316002)(110136005)(33656002)(54906003)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6SPR00MB2470; H:BN3PR05MB2706.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xOajNkVxjVwdB2/L0WAQFcdSXcf1pyVPtAWkMDIwnCsqPThSIuBnpMnScfsh29gZBGV2gzsSP03DplfgQM9KDA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR05MB2706F5D5841EBF0DEA6ADE9AD5170BN3PR05MB2706namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: dea6776e-9bf4-496b-4634-08d559674f2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 02:50:58.6726 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6SPR00MB2470
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120034
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/FS99ii4zpoDTBscLzo3ezJVS0h0>
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, 12 Jan 2018 02:51:09 -0000

OSPF WG,

WG consensus seems to be graceful-link-shutdown.
I’ll update the draft with graceful-link-shutdown and also add some text
Describing this mechanism can also be used when the real intent is not to shutdown
the link.

Let me know if there are any objections.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Monday, January 8, 2018 11:31 PM
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>; Bruno Decraene <bruno.decraene@orange.com>
Cc: Shraddha Hegde <shraddha@juniper.net>; Acee Lindem (acee) <acee@cisco.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel Halpern <jmh@joelhalpern.com>; gen-art@ietf.org; ospf@ietf.org; ietf@ietf.org; draft-ietf-ospf-link-overload.all@ietf.org
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

If the WG consensus is for “GLS” so be it…but I would like to reemphasize two things:

1)There are use cases where the intent is NOT to shutdown the link

2)Once the link is shutdown the extension is no longer used since there is no longer an adjacency – so to me it makes a lot more sense to pick a name which reflects how the link is to be used while it is still up.

   Les



From: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
Sent: Monday, January 08, 2018 9:22 AM
To: Bruno Decraene <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; gen-art@ietf.org<mailto:gen-art@ietf.org>; ospf@ietf.org<mailto:ospf@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Hi Joel et al,

+1 for 'graceful-link-shutdown'. Another possibility may be 'link-decommission'..

Thanks and regards
-Pushpasis

On Mon, Jan 8, 2018 at 7:09 PM, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:


From: Shraddha Hegde
How about “graceful-link-shutdown” ?

Looks good to me.

Also, FYI, for BGP sessions, in the GROW WG we used the term “Graceful BGP session shutdown” and named the BGP community “GRACEFUL_SHUTDOWN” so this would align on the terminology.
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-13<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbgp-2Dgshut-2D13&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=j5OSxniUADg7fBg9lmrSvsTWGWY_VhCl-Ydi9t0XfFI&s=R0GJNP0TbKHBFiCCQKwDlB7YVSgmQsq4p7JvCtd_leM&e=>

Best regards,
--Bruno


Rgds
Shraddha



From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is better than “overload”. “pending-maintenance” is a bit long which is why I suggested “pending-shutdown” since “shutdown” is term that vendors have used for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com<mailto:ketant@cisco.com>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, "gen-art@ietf.org<mailto:gen-art@ietf.org>" <gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>, "draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>" <draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful Insertion/Removal (GIR) Mode” which could be defined so as to cover the multiple scenarios in question (e.g. pending shutdown, down for repairs, last resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, "gen-art@ietf.org<mailto:gen-art@ietf.org>" <gen-art@ietf.org<mailto:gen-art@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>, "draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>" <draft-ietf-ospf-link-overload.all@ietf.org<mailto:draft-ietf-ospf-link-overload.all@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


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

That is not the use case - you are going to take the link down. It is not going to be the "link of last resort”, it is the currently the “link of last resort” and will imminently be taken down.




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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc3277_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=769ndBiWrwubwBNccNtOnDuHr1yMD-W10WuEarCDNgI&e=> )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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Disis-2Dreverse-2Dmetric-2D07-23section-2D3.6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=r_8muG61-ePlkCbqf7qIcHUPHGtjWf_JOH1UXH7lp8U&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dlink-2Doverload-2D11&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=umZHmgXp6i4i0PAyZbsDS0iorBurDZsFIyvaVVXEHb0&e=> . 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.

Agreed.

Thanks,
Acee



   Les



> Thanks,

> Acee

> >

> >

> >

>

> _______________________________________________

> OSPF mailing list

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

> https://www.ietf.org/mailman/listinfo/ospf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ospf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=N51dsQzqzgGoBY61VJtqkgGHlrNjgZT_-9g8G_pcOyE&e=>

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.