Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Pushpasis Sarkar <> Tue, 29 September 2015 12:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 494101B3286 for <>; Tue, 29 Sep 2015 05:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i6STWfZyR81V for <>; Tue, 29 Sep 2015 05:25:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CDBC1B327C for <>; Tue, 29 Sep 2015 05:25:20 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 29 Sep 2015 12:25:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.0280.017; Tue, 29 Sep 2015 12:25:18 +0000
From: Pushpasis Sarkar <>
To: "Acee Lindem (acee)" <>, Shraddha Hegde <>, OSPF WG List <>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ+rHmcRhLA+ujBk6ruiEe/oRn0A==
Date: Tue, 29 Sep 2015 12:25:18 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1388; 5:JrM96TsLR5uxwoK5ObN6yWvILEoggoQGU/7dobsM7+pTl2DHp5NSHt8teBQRLwziQztb1WtfAQnpK4L+aRJvtCMo6g4xy7Os5Qmj7j2JzLI7YVnNazMHD5f7D8/XY6I+Xjw+TWalpjQKYdN6/ssBIA==; 24:i/izyGMI0K2CJHon8eCxQFWvZOi5AVRnwRH6UjIzKJQbRoJPDlBHB/S8xojGek33NmxXTIIfEfmJJ4d58bRdFYlcTmC08FsplpsRfU5BWIs=; 20:1e+jnpshO8huwxhu0WAGJA4+0tKFUjTY5VNSIAac1Yj5AFGYZBcUn5VZkvuwNreSPn4SW4NKylQfKfJfsXqG2g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1388;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CY1PR0501MB1388; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1388;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(199003)(189002)(36756003)(105586002)(5004730100002)(101416001)(77156002)(77096005)(106116001)(106356001)(68736005)(93886004)(62966003)(102836002)(40100003)(5007970100001)(122556002)(99286002)(230783001)(50986999)(54356999)(33656002)(561944003)(76176999)(5002640100001)(10400500002)(5001960100002)(2900100001)(4001540100001)(87936001)(83716003)(2950100001)(83506001)(82746002)(19580405001)(19580395003)(189998001)(5001830100001)(86362001)(97736004)(81156007)(5001770100001)(4001350100001)(64706001)(46102003)(1941001)(92566002)(5001860100001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1388;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2015 12:25:18.5263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1388
Archived-At: <>
Cc: Hannes Gredler <>, 'Mohan Nanduri' <>, "Jalil, Luay" <>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 12:25:25 -0000

Hi Acee,

On 9/29/15, 5:17 PM, "Acee Lindem (acee)" <> wrote:

>You still didn’t answer my question. Why would the action for TE LSPs not
>always be to divert the traffic when the TE metric on one of the component
>links is 0xfffffffe. You still have not convinced me that the additional
>link attribute provides any value add beyond setting the metric to 0xffff
>and TE Metric to 0xfffffffe.

[Pushpasis] Couple of reasons why I feel Link overload is better.
1. Logically I feel flag is better than a meaning associated with a special value of a attribute which does not indicate the same exact condition. 
2. There is already a 'node-overload' mechanism for taking out a router for maintenance. And so using a ‘link-overhead’ seemed more logical approach.
3. Finally, a metric is applicable in one direction only. This means, while taking out a link for maintenance the operator needs to manually set the metric (with special value) on both sides of the link. However with this proposal operator needs to set the overload on one side of the link and the other-side of the link will automatically put the link on overload and that will take both-side transient traffic off the link.
4. Additionally, the overload attribute can help the controller distinguish between a link that has been intentionally taken out of service versus a link that whose metric has degraded due to other reasons (e.g. a link may metric may dynamically degraded due to some change in S/N ratio etc).