On 10/5/15, 10:17 AM, "Anil Kumar S N (VRP Network BL)" <[email protected]> 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:[email protected]] >> 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)" >> <[email protected]> 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:[email protected]] 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)" <[email protected]> >> >> 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 >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
