Alexander Okonnikov <alexander.okonni...@gmail.com> writes: >> no argument about the need of area level flooding - Router LSA with >> the max metric will be flooded within the area. >> >> I have read the section 7.2 several times, but I still do not >> understand what is the purpose of the Link-Overload sub-TLV there. >> What is the controller going to do when it receives the area scoped >> Link-Overload sub-TLV and how it is different to the case where the >> link is advertised in the Router LSA with max-metric in both directions?
> The fact that link metric has been maximized could not be a trigger for > LSP recalculation. Some implementations consider IGP topology change as > a trigger for LSP recalculation, but others - don't. Also, max metric But you have to change the code anyway to make a new TLV work, right? So what old code does isn't really relevant, unless I misunderstand things. > itself doesn't tell about exact reason for what link metric was > increased. It could be result of IGP-LDP synchronization, for example, > which is irrespective to TE LSPs. From the other hand, when > head-end/controller receives explicit indication (Link-overload), it > could interpret it safely as a trigger to reroute LSP, even if > overloaded link is only link that satisfies constrains (from CSPF > perspective). Otherwise, increased metric could not be enough reason to > relax constrains for LSP. But IGP-LDP synchronization happens when a link initially comes up. Is the point then of the new TLV to simply avoid this slight delay on link-up in using the link for TE? Thanks, Chris.
signature.asc
Description: PGP signature
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
