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

"Acee Lindem (acee)" <> Tue, 29 September 2015 12:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2EE2D1B378D for <>; Tue, 29 Sep 2015 05:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yaqHzZDhFBX5 for <>; Tue, 29 Sep 2015 05:37:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8D901B3783 for <>; Tue, 29 Sep 2015 05:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3384; q=dns/txt; s=iport; t=1443530236; x=1444739836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=j99IqvDRjiRort5VXl+Bxfj8a3+0xC6lJ2Snb0HxBhA=; b=gL16QTL46WKtHbqVnMM750ySY0bbrffDS2uaCnan7BZNO1lYQCmcQ1Wp fNvTBk7/UUnHvsywbDtQisP+TUPKXs8HeA0GS5MvQnQDJL8etYwjwDT29 d2Of6pPOeIAOtOZVaNNzRvCjIQaZrPD/gCDT8i/FFPkDCd7OGZ9NWeyLM A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,608,1437436800"; d="scan'208";a="32984274"
Received: from ([]) by with ESMTP; 29 Sep 2015 12:37:16 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8TCbG72010993 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 12:37:16 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 07:37:15 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 07:37:15 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 07:37:14 -0500
From: "Acee Lindem (acee)" <>
To: Pushpasis Sarkar <>, Shraddha Hegde <>, OSPF WG List <>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Date: Tue, 29 Sep 2015 12:37:14 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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:37:23 -0000

Speaking as a WG participant:

Hi Pushpasis, 

We seem to be a having a failure to communicate.

On 9/29/15, 8:25 AM, "Pushpasis Sarkar" <> wrote:

>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
>>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
>2. There is already a 'node-overload' mechanism for taking out a router
>for maintenance. And so using a ‘link-overhead’ seemed more logical

So, to sum up #1 and #2, you feel this approach is more “logical”. This is
a subjective argument.

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

The alternative is using link-local signaling to tell the neighbor that
the link is going down for maintenance. Hence, the metric and TE metric
are set in both directions. I thought we already established that there is
no debate on this issue. Hopefully, we can refrain from any more lengthy
explanations on setting the metrics or how TE works.

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

Which bring us back to my original question that is still unanswered, why
would the controller action of diverting traffic be any different for an
LSP on which one of the component links has max metric?