Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
"Acee Lindem (acee)" <acee@cisco.com> Mon, 28 September 2015 13:32 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 639331A90EB for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 06:32:21 -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 lFudmi24Adn7 for <ospf@ietfa.amsl.com>; Mon, 28 Sep 2015 06:32:19 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A0F1A90EA for <ospf@ietf.org>; Mon, 28 Sep 2015 06:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5778; q=dns/txt; s=iport; t=1443447139; x=1444656739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hLoeuFwZk0kc3P228N8hhhretGbkVyEdQzeJAZ5K0Lg=; b=gwnzVXeyIErRcHIw8CnNjL91juEG8zWpzBlIw2FvsXLmvI06UnXMKXrS oArYmXjaBUQlVWfL9hLVGr//C+Fbenwahb8EZGfQ2cbBra65TRKUABtCC dF2bxiTbZ2N0WjDDStTHTW9pl5Zg17eO+X8+BwK594bQxDdcweF/vpNx4 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D0AQDyQAlW/4MNJK1egyRUaQa9OAENgXEKgkODNgIcgSY4FAEBAQEBAQGBCoQkAQEBAwEBAQEgEToLDAQCAQgRBAEBAwIjAwICAiULFAEICAIEAQ0FG4gLCA22Z5Q8AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIopOhEsPMwcGgmOBQwWVcAGNDoFPhDaRTYNtHwEBQoQBcYdbQYEFAQEB
X-IronPort-AV: E=Sophos;i="5.17,602,1437436800"; d="scan'208";a="30775024"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 28 Sep 2015 13:32:18 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8SDWI8d004801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 13:32:18 GMT
Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 08:32:17 -0500
Received: from xhc-aln-x09.cisco.com (173.36.12.83) by xch-rcd-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 08:32:17 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 08:32:17 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, OSPF WG List <ospf@ietf.org>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ9/MdJMB0YsR7d0CkMD6XMtCYyZ5RXZAwgACngYA=
Date: Mon, 28 Sep 2015 13:32:17 +0000
Message-ID: <D22EB65C.32FF9%acee@cisco.com>
References: <D22B605B.32E55%acee@cisco.com> <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.26]
Content-Type: text/plain; charset="utf-8"
Content-ID: <CFF4AF9C47162A429CAAB405636EA6DB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/CgJo2azgiWLkL9BA7Rasi_HFbFo>
Cc: Hannes Gredler <hannes@gredler.at>, "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: Mon, 28 Sep 2015 13:32:21 -0000
Hi Shraddha, On 9/28/15, 1:13 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. I’m not sure why anyone would even consider using a mechanism other than the metric to divert IP routed traffic. I don’t think we need to discuss this any further as it only dilutes the discussion of the real questions. > > 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. Why does the controller care whether the link is out of service due to maintenance or some other reason? In any case, the link is unavailable and TE traffic should be diverted. > > >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. In a completely automated upgrade process, the controller would be orchestrating the link maintenance and wouldn’t require the router to tell them about it. > > >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. There is no disagreement about using metric to divert traffic or why the reverse metric must be increased as well - no more discussion is necessary. > >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. I think one point that would be good to explain is why OSPF stub router alone isn’t enough to support link maintenance. Thanks, Acee > >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] OSPF Link Overload - draft-hegde-ospf-link… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Les Ginsberg (ginsberg)
- [OSPF] FW: OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] FW: OSPF Link Overload - draft-hegde-o… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Ahmed Bashandy (bashandy)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Les Ginsberg (ginsberg)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Les Ginsberg (ginsberg)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Anil Kumar S N (VRP Network BL)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Uma Chunduri
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Pushpasis Sarkar
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Manav Bhatia
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Anil Kumar S N (VRP Network BL)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Shraddha Hegde
- Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-… Acee Lindem (acee)