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

"Acee Lindem (acee)" <> Tue, 29 September 2015 14:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 92A961A9141 for <>; Tue, 29 Sep 2015 07:45:59 -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 iDFwlTMKfkKX for <>; Tue, 29 Sep 2015 07:45:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31D311A9148 for <>; Tue, 29 Sep 2015 07:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5144; q=dns/txt; s=iport; t=1443537958; x=1444747558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dkfihnqMzMtvhF4iTO1YM3eUnOMQSCL+DV8BLUEEBTY=; b=LlkOBcX/z5L7zX5Vc7ea94RBqos7Zig/MhyVAYCOri719osokpwRuLjx I3WZjFj+KrCdwvsJfBpZErFIK5mbQIpPTnbe9bCXzbqBvJtF9HORdwIsE vpwVavJUBSY/olk4+CVV3A1QsejyxB9pRtWDjqdyeL5BqXm4fMzOKez96 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,608,1437436800"; d="scan'208";a="192633440"
Received: from ([]) by with ESMTP; 29 Sep 2015 14:45:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8TEjvEV011956 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 14:45:57 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 09:45:56 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 09:45:56 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 09:45:40 -0500
From: "Acee Lindem (acee)" <>
To: Pushpasis Sarkar <>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Date: Tue, 29 Sep 2015 14:45:55 +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 <>, OSPF WG List <>, "Jalil, Luay" <>, Mohan Nanduri <>
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 14:45:59 -0000

Hi Pushpasis, 

> On Sep 29, 2015, at 10:23 AM, Pushpasis Sarkar <> wrote:
> Hi Acee,
> On 9/29/15, 6:07 PM, "Acee Lindem (acee)" <> wrote:
>> Speaking as a WG participant:
>> Hi Pushpasis, 
>> We seem to be a having a failure to communicate.
> [Pushpasis] I am very sorry if I have really broken the communication channel here. But I thought we were communicating well so far :)

I apologize if I offended you. I just wanted to avoid the circular discussions and repetition of information having no bearing on the issues raised.  

>> On 9/29/15, 8:25 AM, "Pushpasis Sarkar" <> wrote:
>>> On 9/29/15, 5:17 PM, "Acee Lindem (acee)" <> wrote:
>> So, to sum up #1 and #2, you feel this approach is more “logical”. This is
>> a subjective argument.
> [Pushpasis] Offcourse, all the points here is my personal opinion. I don’t claim that they are anyone else’. Others may or may not agree with them.
>> 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.
> [Pushpasis] But the alternative you are suggesting does not seem to be specified in any document so far. I maybe wrong, but I thought this way of signaling to the neighbor about the link is going down on this side and asking neighbor to take down at his end was being proposed for the first-time in this document. You can correct me if my knowledge / understanding is wrong, and I shall take back statement immediately.

The link-local signaling alternative was suggested to satisfy this use case both times this draft was presented in OSPF WG meetings. I’m glad we don’t have a competing document since that is always painful to resolve. 

>> 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?
> [Pushpasis] Like mentioned already, and again in my opinion, this will help the controller deal with scenarios where it needs to distinguish between situations in which a link has been administratively put into ‘out-of-order’ from situations where the link has degraded to a ‘malfunctioning’ state and needs attention. Unfortunately I cannot come up with a use-cases how this distinction can be used (other than diverting service traffics away from the links). Perhaps some of the operators may throw more light.

I’d like to hear from the operators (especially the authors Luay and Mohan). 

> Hoping I have not failed to communicate once more. If you still feel so, please let me know. And I will refrain myself from answering on this thread further.

I think we are communicating now - the main question is what does this link-maintenance condition needs to be flooded throughout the OSPF routing domain when it seems that link-local signaling would offer a much more straight-forward solution. The response so far has been, “For the controller use-case” without any explanation of why increasing the forward and reverse metrics isn’t enough (especially since you are doing this anyway for backward compatibility). Les Ginsberg raised the same point.


> Thanks once again and regards.
> -Pushpasis
>> Thanks,
>> Acee
>>> Thanks
>>> -Pushpasis