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

Manav Bhatia <manavbhatia@gmail.com> Wed, 30 September 2015 14:02 UTC

Return-Path: <manavbhatia@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34021A874A for <ospf@ietfa.amsl.com>; Wed, 30 Sep 2015 07:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXmeQFOx6u7H for <ospf@ietfa.amsl.com>; Wed, 30 Sep 2015 07:02:27 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCC81A8757 for <ospf@ietf.org>; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
Received: by oibi136 with SMTP id i136so22666157oib.3 for <ospf@ietf.org>; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.202.191.135 with SMTP id p129mr2314517oif.8.1443621744146; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
Received: by 10.76.76.199 with HTTP; Wed, 30 Sep 2015 07:02:24 -0700 (PDT)
In-Reply-To: <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <D22B605B.32E55%acee@cisco.com> <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
Date: Wed, 30 Sep 2015 19:32:24 +0530
Message-ID: <CAG1kdoi1F3uX18xGf+QzRaZ4nCF43tbgHmD9aFfOs-5JFvNRVA@mail.gmail.com>
From: Manav Bhatia <manavbhatia@gmail.com>
To: Shraddha Hegde <shraddha@juniper.net>
Content-Type: multipart/alternative; boundary=001a113dddfc3fffe50520f7611d
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/aBYBoc0g2gSwt6yR8iSYtP2lA8g>
Cc: Hannes Gredler <hannes@gredler.at>, OSPF WG List <ospf@ietf.org>, "Jalil, Luay" <luay.jalil@verizon.com>, Mohan Nanduri <mnanduri@microsoft.com>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 14:02:30 -0000

Hi,

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 <shraddha@juniper.net>
wrote:

> 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 [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
> Sent: Saturday, September 26, 2015 6:05 AM
> To: OSPF WG List <ospf@ietf.org>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>