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

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

Return-Path: <acee@cisco.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 1C5481B2D7C for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 20:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvmQFN94kP7C for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 20:01:36 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB751B2D84 for <ospf@ietf.org>; Mon, 28 Sep 2015 20:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0AKAgC4/QlW/5xdJa1egyRUaQa9PQENgXEKgkODNgIcgS04FAEBAQEBAQGBCoQkAQEBBAEBASAROhcEAgEIEQQBAQMCIwMCAgIlCxQBBwEIAgQBEhuHfgMSDbZ3lFABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiik6CUIF7JyIGgmOBQwWFfI92AYUUh3yBT4Q2kU2Dbx8BAUKEAXGHWUGBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,605,1437436800"; d="scan'208";a="36293175"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 29 Sep 2015 03:01:35 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-5.cisco.com (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 xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 22:01:34 -0500
Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-rcd-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 22:01:34 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 22:01:34 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, OSPF WG List <ospf@ietf.org>
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: <D22F76C7.331E6%acee@cisco.com>
References: <D22B605B.32E55%acee@cisco.com> <BY1PR0501MB1381BC32F814F90F5FDFF2F9D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB1381BC32F814F90F5FDFF2F9D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.101.220.158]
Content-Type: text/plain; charset="utf-8"
Content-ID: <45AF06E83AE18B46A8EB958A65AE283C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/qi9CUjJ_9_3ligV6y5_-QADnlrI>
Subject: Re: [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 03:01:38 -0000

Hi Shraddha, 
This was two and there were, at least, two responses. Please refer to the
archive: https://mailarchive.ietf.org/arch/search/?email_list=ospf

Thanks,
Acee

On 9/28/15, 10:56 PM, "OSPF on behalf of Shraddha Hegde"
<ospf-bounces@ietf.org on behalf of shraddha@juniper.net> wrote:

>Resending to mailing list as I didn't see it delivered in last posting...
>
>Rgds
>Shraddha
>
>-----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>er.at>; 'Mohan Nanduri' <mnanduri@microsoft.com>om>; 'Jalil,
>Luay' <luay.jalil@verizon.com>
>Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01
>
>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