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

Shraddha Hegde <shraddha@juniper.net> Tue, 29 September 2015 02:57 UTC

Return-Path: <shraddha@juniper.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 34E951B2D88 for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 19:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rCoHLNo1kaLG for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 19:57:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1111E1B2D82 for <ospf@ietf.org>; Mon, 28 Sep 2015 19:57:04 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ( by BY1PR0501MB1381.namprd05.prod.outlook.com ( with Microsoft SMTP Server (TLS) id; Tue, 29 Sep 2015 02:56:45 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([]) with mapi id 15.01.0280.017; Tue, 29 Sep 2015 02:56:45 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: OSPF WG List <ospf@ietf.org>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ9/MdJMB0YsR7d0CkMD6XMtCYyZ5RXZAwgAF3RgA=
Date: Tue, 29 Sep 2015 02:56:45 +0000
Message-ID: <BY1PR0501MB1381BC32F814F90F5FDFF2F9D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <D22B605B.32E55%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1381; 5:m+T2/Q6CJO2+0XsGz2Tx5C6CItiAr1LL/Ra6zWGdwf+HYr3tYHdQIt7jmkjVZHGbW8G9VL1nzq0k+eaHFGQFoawWA8ln583C6ECAzY+SN0HaJIy73Y49jcrkLgTwkOG2oo/SXpnpx5x3IKVJEw++iw==; 24:QjFAJdB/aCIPAPbI5ymopQVgC8enRsjCdbcrqPu3zlJQvSyIHLXjchX/iM3I00OqfkVwixqKEjbV6v2EhLmTWCUTmivU0hd79G8TU/XaTqk=; 20:3S4vqDygeGMlts02nhbDAhOMI9wDFfUNUdLJVzO/iJ4mH8PfH0vU6Lhk0r0hoMA1Km2vYD1p6JZVhClOZ2PVCw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381;
x-microsoft-antispam-prvs: <BY1PR0501MB1381BD45EFF2B5B5048C5022D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BY1PR0501MB1381; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(52604005)(164054003)(199003)(377454003)(189002)(64706001)(54356999)(122556002)(40100003)(230783001)(106116001)(101416001)(33656002)(50986999)(76176999)(106356001)(76576001)(74316001)(66066001)(46102003)(107886002)(5007970100001)(11100500001)(77096005)(5004730100002)(4001540100001)(5002640100001)(68736005)(10400500002)(87936001)(189998001)(110136002)(19580405001)(19580395003)(15975445007)(102836002)(5003600100002)(5001960100002)(2900100001)(105586002)(99286002)(5890100001)(5001830100001)(86362001)(5001860100001)(92566002)(450100001)(81156007)(77156002)(97736004)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2015 02:56:45.6899 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1381
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/xG_KUF054IpRqp9gFgU6hvI8jlk>
Subject: [OSPF] FW: 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: Tue, 29 Sep 2015 02:57:09 -0000

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)' <acee@cisco.com>om>; OSPF WG List <ospf@ietf.org>
Cc: Pushpasis Sarkar <psarkar@juniper.net>et>; Hannes Gredler <hannes@gredler.at>at>; 'Mohan Nanduri' <mnanduri@microsoft.com>om>; 'Jalil, Luay' <luay.jalil@verizon.com>
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 [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. 


OSPF mailing list