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

"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Mon, 05 October 2015 14:18 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 9BD8C1ACE31 for <ospf@ietfa.amsl.com>; Mon, 5 Oct 2015 07:18:23 -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 Zh2SxHRo-8iK for <ospf@ietfa.amsl.com>; Mon, 5 Oct 2015 07:18:22 -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 C29401ACE46 for <ospf@ietf.org>; Mon, 5 Oct 2015 07:17:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCC09192; Mon, 05 Oct 2015 14:17:30 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Oct 2015 15:17:29 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Mon, 5 Oct 2015 22:17:26 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Pushpasis Sarkar <psarkar@juniper.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ+rHmcRhLA+ujBk6ruiEe/oRn0J5RXZAwgACngYCAAOZAsIAAjtgA///5vgCAAANVAIAAHdGAgAAGI4CAAAMzAIAAHeHwgAA2qwCAAHDQUP//jg2AgAAL1wCAAIcG8IAH6MmAgACNFMA=
Date: Mon, 5 Oct 2015 14:17:25 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF06C063B5C@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> <327562D94EA7BF428CD805F338C31EF06C06250B@nkgeml512-mbx.china.huawei.com> <D237F757.33DDD%acee@cisco.com>
In-Reply-To: <D237F757.33DDD%acee@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.92]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/jp2LdBzhjzQ7-pMHneecwGjjG8g>
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: Mon, 05 Oct 2015 14:18:23 -0000

Acee, 

	In My implementation, I sort all the connecting link paths. 
	I choose best link cost available, if not then I will use last resort max cost Link path.

	Anyways this draft is complimenting your case :) 

	A---B
	Lets say A is a P node and B is a Q node where B is under maintaince, makes B to a Link as Max Metric.
	Now you will still be using link A--B as A to B link cost is not updated. 

	This draft insists A to update its cost to Max metric, Which will force you to choose different link.

Thanks & Regards
Anil S N

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



> -----Original Message-----
> From: Acee Lindem (acee) [mailto:acee@cisco.com]
> Sent: 05 October 2015 19:18
> To: Anil Kumar S N (VRP Network BL); Pushpasis Sarkar; Les Ginsberg
> (ginsberg); Shraddha Hegde
> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
> Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> Anil,
> 
> On 9/30/15, 1:25 AM, "Anil Kumar S N (VRP Network BL)"
> <anil.sn@huawei.com> wrote:
> 
> >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.
> 
> It is already advertised at max-metric, for LFA/RLFA my implementation
> (Ericsson) avoided using max-metric links…
> 
> Acee
> 
> 
> >
> >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