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

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