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

"Acee Lindem (acee)" <> Tue, 29 September 2015 03:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C5481B2D7C for <>; Mon, 28 Sep 2015 20:01:38 -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 zvmQFN94kP7C for <>; Mon, 28 Sep 2015 20:01:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CB751B2D84 for <>; Mon, 28 Sep 2015 20:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5720; q=dns/txt; s=iport; t=1443495696; x=1444705296; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/qC4pyEQguXE1f6YFfyvqIWABQjxC+8aInPtUfG7nRY=; b=l2ej2pLfLBs77FnW4PR7oXAMDw32Cd5nVPsRdLqaGjqY3W0ZFnDkUl7Y HwKHXUhCXQkmHm2N5aPHf04WDdQ1lhzLWEcmgrd33dJFCRsixny9OuGw6 xvRmXan+BVpplvV65EP1VwfejkaswKCZyNcNXXLrDY0uFvIg5XTZeo+Bd c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,605,1437436800"; d="scan'208";a="36293175"
Received: from ([]) by with ESMTP; 29 Sep 2015 03:01:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8T31Z6G004002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 03:01:35 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 22:01:34 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 22:01:34 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 22:01:34 -0500
From: "Acee Lindem (acee)" <>
To: Shraddha Hegde <>, OSPF WG List <>
Thread-Topic: [OSPF] FW: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ+mKMLnoou2U71UWkaXKgsS+fRJ5S4lCA
Date: Tue, 29 Sep 2015 03:01:34 +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: <>
Subject: Re: [OSPF] FW: 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 03:01:38 -0000

Hi Shraddha, 
This was two and there were, at least, two responses. Please refer to the


On 9/28/15, 10:56 PM, "OSPF on behalf of Shraddha Hegde"
< on behalf of> wrote:

>Resending to mailing list as I didn't see it delivered in last posting...
>-----Original Message-----
>From: Shraddha Hegde
>Sent: Monday, September 28, 2015 10:43 AM
>To: 'Acee Lindem (acee)' <>om>; OSPF WG List <>
>Cc: Pushpasis Sarkar <>et>; Hannes Gredler
><>>; 'Mohan Nanduri' <>om>; 'Jalil,
>Luay' <>
>Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01
>Thanks for picking up the draft for adoption.
>I believe this draft is very useful in automating the link upgrade
>process and software upgrade process in overlay deployments and hence
>support WG adoption as co-author.
>I would like to  take this opportunity to discuss  few of the points
>raised during Prague meeting.
>1. Whether to keep the "Link overload" advertisement at area level or at
>link level.
>In controller based deployments, it's useful to advertise the impending
>maintenance of the link to the controller so that controller can take
>Special actions based on the information. The use case is described in
>sec 5.2 in  the draft.
>The draft advocates increasing the metric to usable high metric on both
>ends of the link. This is for backwards compatibility and to avoid need
>of flag Day upgrade on all nodes.
> Controller cannot assign special meaning to the metric  for ex: Metric
>XXXX means the link going for maintenance and take different actions
>based on metric. 
>For a completely automated upgrade process, controller would need a fine
>grained and specific information that the link is going for maintenance
>so that the services that use the particular link find a different path
>forcefully while keeping the entire process non-disruptive.
>2. Use of high metric  on either side of the link  to divert the traffic.
>As I already mentioned before, draft advocates raising the reverse metric
>to a high metric  but that is for backwards compatibility and to avoid
>Need for flag-day upgrade. There were suggestions at the Prague meeting
>to use lower bandwidth advertisements as well as removal of Link
>characteristics to force the services on different path. These mechanisms
>would be disruptive and defeats the purpose of the draft.
>3.  Backward compatibility
>"Link-overload"  is a new information attached to a link and is very
>similar to a new constraint being added to the link.
>This information is non-invasive in the sense that services that do not
>want to look at the new constraint (link overload) May depend only on the
>metric to take specific actions.
>Whereas services that have specialized requirement of providing
>non-disruptive upgrades can do so by processing the new constraint.
>Section 4 in the draft talks about backwards compatibility.
>I'll add more clarifications in the coming days.
>-----Original Message-----
>From: OSPF [] On Behalf Of Acee Lindem (acee)
>Sent: Saturday, September 26, 2015 6:05 AM
>To: OSPF WG List <>
>Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
>In Prague, there was consensus in the room that this use case was not
>covered by existing mechanisms and that it was a problem the WG should
>solve. There were differing opinions as to the exact solution but that
>should not preclude OSPF WG adoption.
>Please indicate your support (or concerns) for adopting this as a WG
>OSPF mailing list
>OSPF mailing list