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

Pushpasis Sarkar <> Tue, 29 September 2015 14:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 777E51B43FB for <>; Tue, 29 Sep 2015 07:57:47 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iSinImQ6xrSJ for <>; Tue, 29 Sep 2015 07:57:45 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE01D1B43FE for <>; Tue, 29 Sep 2015 07:57:44 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 29 Sep 2015 14:57:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0280.017; Tue, 29 Sep 2015 14:57:23 +0000
From: Pushpasis Sarkar <>
To: "Acee Lindem (acee)" <>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ+rHmcRhLA+ujBk6ruiEe/oRn0A==
Date: Tue, 29 Sep 2015 14:57:22 +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; BN3PR0501MB1380; 5:Cw/hDNJ5qpZVltCv2gMxaEOJK6LRLfb9zF31oMTtmW0q2FWF7kCK7FBzguiaqn3m+tOyCU3B40vfjgMRwBKbZs78foh6kTTDX3WKCEAkd23TG8/O5fJ3uNDH/1dzYN7K2l1unoEJe9kX9/wevKPyXw==; 24:JxtAr5j2+8MSbqLNpU0X5u1mtfWA1RW942nXQOL+Z1flSxl+n/er/KaayYKx3+3XOP3uOzhCb1igpaOtJJEoXHz377s17Z5oa7FmXs5MXoo=; 20:HdqGsAO3VJmyORhdpMvG7TaUsGoInj207sD79BbV1AjzSPbssTV7SdlWhFfdx+hdJkH+gZVmannro8W9Kknitw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1380;
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:BN3PR0501MB1380; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1380;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(51694002)(199003)(189002)(377454003)(479174004)(105586002)(5002640100001)(102836002)(77096005)(99286002)(11100500001)(87936001)(76176999)(110136002)(106356001)(106116001)(68736005)(122556002)(92566002)(10400500002)(62966003)(54356999)(83716003)(64706001)(33656002)(93886004)(40100003)(189998001)(66066001)(5001960100002)(50986999)(2950100001)(46102003)(230783001)(101416001)(2900100001)(19580405001)(86362001)(19580395003)(77156002)(4001540100001)(81156007)(83506001)(5004730100002)(5001860100001)(4001350100001)(97736004)(82746002)(5007970100001)(5001830100001)(36756003)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1380;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:;
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 14:57:23.0586 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1380
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:57:47 -0000

Hi Acee,

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

>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.  
[Pushpasis] No no. You have not offended me in any ways. So we are good then. I was worried that I might have offended you instead. :)
>> [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).
[Pushpasis] Me too :)
>> 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.
[Pushpasis] I will not further exaggerate my already-expressed reasoning as I do not have a definite use case in hand. Hoping some operators in the working group may have more solid use-cases for this.

Thanks and Regards,