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

["Acee Lindem (acee)" <[e-mail]>]

On 10/5/15, 10:17 AM, "Anil Kumar S N (VRP Network BL)"
<[e-mail]> wrote:

>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.

Right - max-metric in both directions is enough for all flavors of LFA. I
was referring to the necessity of the OSPFv2 link attribute for the the
LFA use-cast. 

Thanks,
Acee 


>
>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:[e-mail]]
>> 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)"
>> <[e-mail]> 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:[e-mail]] 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)" <[e-mail]>
>> >> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ospf
>