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

Manav Bhatia <> Wed, 30 September 2015 14:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E34021A874A for <>; Wed, 30 Sep 2015 07:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tXmeQFOx6u7H for <>; Wed, 30 Sep 2015 07:02:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBCC81A8757 for <>; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
Received: by oibi136 with SMTP id i136so22666157oib.3 for <>; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r8as825VjEfxLMIHrkbP5Mo43L97Z0wsMg7XIaI1La4=; b=pPMzMEfqaFYDvvJ2Oxw5PAJe0ozftVE6UCz/2nJ2bVB1dF8CwRP6lbbVZOyxtZQU+j SP+rqpdpCbpf4Rm4TP4msfCYQapuHe4t8euyEZspdrd2YkZWC4/VQSUTGdp+8OWliDBr TUsr1FhbSIIVwEzklXsDX+G1RFlx6BQqoBCkg2YTkq3FjmjDCt/oUgmixYToIeVT863I 2nubzJm31WDYjrTLS707STpiEtI4oJYkJV2X5+xg3Lgi3sMvbVAeSw1uxWmxo99dLX62 eOae3O7JyT7TVzaTBjBr9RKn7YHVvQtXVkeI7m+G1dr8K7n+MmlXVdYv0xcw6MUIxMmI D5tw==
MIME-Version: 1.0
X-Received: by with SMTP id p129mr2314517oif.8.1443621744146; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
Received: by with HTTP; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 30 Sep 2015 19:32:24 +0530
Message-ID: <>
From: Manav Bhatia <>
To: Shraddha Hegde <>
Content-Type: multipart/alternative; boundary=001a113dddfc3fffe50520f7611d
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: Wed, 30 Sep 2015 14:02:30 -0000


I am probably joining the party quite late, so apologies in advance if the
following has already been discussed and discarded.

Why cant the following be done:

Set the metric of all transit links/connections on an “overloaded” router
to 0xffff in its Router LSAs. This will result this router to not be
included as a transit node in its neighbors SPF tree.  Stub links can still
be advertised with their normal metrics so that they are reachable even
when a router is “overloaded”.

This way you can mimic IS-IS OL bit.

Cheers, Manav

On Mon, Sep 28, 2015 at 10:43 AM, Shraddha Hegde <>

> Acee,
> 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.
> Rgds
> Shraddha
> -----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
> Document.
> Thanks,
> Acee
> _______________________________________________
> OSPF mailing list
> _______________________________________________
> OSPF mailing list