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

"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Wed, 30 September 2015 05:26 UTC

Return-Path: <anil.sn@huawei.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 18B8C1B5C43 for <ospf@ietfa.amsl.com>; Tue, 29 Sep 2015 22:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FC-eKsRfr9_4 for <ospf@ietfa.amsl.com>; Tue, 29 Sep 2015 22:26:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7661B1B5C41 for <ospf@ietf.org>; Tue, 29 Sep 2015 22:26:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBW74426; Wed, 30 Sep 2015 05:26:06 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 30 Sep 2015 06:26:04 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 30 Sep 2015 13:25:57 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: Pushpasis Sarkar <psarkar@juniper.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Shraddha Hegde <shraddha@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ+rHmcRhLA+ujBk6ruiEe/oRn0J5RXZAwgACngYCAAOZAsIAAjtgA///5vgCAAANVAIAAHdGAgAAGI4CAAAMzAIAAHeHwgAA2qwCAAHDQUP//jg2AgAAL1wCAAIcG8A==
Date: Wed, 30 Sep 2015 05:25:56 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF06C06250B@nkgeml512-mbx.china.huawei.com>
References: <D22B605B.32E55%acee@cisco.com> <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D22EB65C.32FF9%acee@cisco.com> <BY1PR0501MB138107954EB733C69D388CC7D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D22FF12A.3323C%acee@cisco.com> <F41DF673-765D-44B2-9499-E47F3D2EABB7@juniper.net> <D22FFBCB.3325F%acee@cisco.com> <0E0FB058-0DC6-49BD-95BC-6E64584B1DAD@juniper.net> <C4D23725-19FA-4B30-9496-486836E001DA@cisco.com> <03C3AD8C-BA1F-4951-BE7E-367C95535484@juniper.net> <BY1PR0501MB1381D96FA2F88CF374D7E3C8D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com> <ba7d718a973d4f17aa0d3392ad9d04c0@XCH-ALN-001.cisco.com> <BY1PR0501MB13810C3D18F95BCADEE0D12BD54D0@BY1PR0501MB1381.namprd05.prod.outlook.com> <39fe6e2522b0468c8eccff66ec701555@XCH-ALN-001.cisco.com> <6A3F4D8E-4D4F-4E9B-8026-1445B73F9BDE@juniper.net>
In-Reply-To: <6A3F4D8E-4D4F-4E9B-8026-1445B73F9BDE@juniper.net>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.212.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/YiQns98g3Y4MEfZPXIX5612VgLs>
Cc: Hannes Gredler <hannes@gredler.at>, OSPF WG List <ospf@ietf.org>, Mohan Nanduri <mnanduri@microsoft.com>, "Jalil, Luay" <luay.jalil@verizon.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 05:26:11 -0000

Hi All,

In support of the draft : draft-hegde-ospf-link-overload-01
Draft makes sense in below scenario I suppose, I could be wrong.

Case where Router detectes some fault in link, would like to advertize link as unusable for a while.

If any router using TI-LFA for FRR might be using this link for stiching P & Q-nodes. 
Link Overload sub TLV might help LFA clacualting node to use some other link for that period of time.

Possibly router under maintainence could be refresh router LSA with out this link, Backward link check fails 
and link under maintaince will not be used. I think this would be treated as topology change which is not the case. 

I feel Overloading Node and Link are done for short period of time and might come handy while debugging/isolating network issues.

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel



> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Pushpasis Sarkar
> Sent: 30 September 2015 10:28
> To: Les Ginsberg (ginsberg); Shraddha Hegde; Acee Lindem (acee)
> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
> Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-
> overload-01
> 
> Hi Les,
> 
> 
> 
> 
> On 9/30/15, 9:45 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
> wrote:
> 
> >><Shraddha>As I indicated before, max-metric can work in most common
> >>scenarios but not all. There could be cases where an alternate path
> >>cannot be found Satisfying the constraints so LSP remains on the link
> >>undergoing maintenance since the link is still a last resort link.
> >
> >[Les:] Which seems to me to be exactly the definition of link of last
> resort i.e. in the absence of any other alternative use the link
> undergoing maintenance.
> >??
> [Pushpasis] What if the operator does not want any traffic on those
> links at all? Should not there be a way to ensure that as well?
> 
> >
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf