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

[Christian Hopps <[e-mail]>]

Alexander Okonnikov <[e-mail]> writes:

> Hi Christian,
>
> See inline.
>
> Thank you.
>
> -- Best regards, Alexander Okonnikov
>
> On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <[e-mail]>, wrote:
>
>  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.
>
> Not sure that understood your point. Yes, implementation that supports this feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but will not necessary do so in response to max
> metric. Former signals that physical/logical link maintenance is planned, latter - that IGP link property is modified (may be due to planned IGP link or IGP process maintenance). Two are not always
> correlate. Ignorance of IGP topology changes from LSP recalculation perspective could be design intent, and not unsupported feature or deficiency of particular implementation. In some implementations
> it could be enabled/disabled by configuration knob. So, even with introducing support of link-overload implementation is not obligated to react to IGP topology changes with LSP recalculation. With 'max
> metric only' approach it is not possible to distinguish whether link metric was increased due to link overload mode, or due to some other reason.

Are these actual scenarios that really matter or would actually be used
by an operator? Do you know of operators that wish to perform "IGP link
maintenance" (not sure how that is different from "link maintenance") on
a link, that doesn't involve simply removing the link from service?

>  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?
>
> Yes, but it is only one of cases. Enabling LDP on link or restarting LDP process, for example, are other viable triggers for 'max metric'. Also, it could be that other usage of 'max metric' will be invented in the
> future.

Max-metric is meant to signal "don't use link if at all possible" nothing
else, there won't be future use that doesn't mean that as well. You're
adding another TLV to signal the exact same intent. I don't see the need
is all.

Thanks,
Chris.

>
>  Thanks,
>  Chris.