Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Christian Hopps <[e-mail]>]

Alexander Okonnikov <[e-mail]> 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.