Hi Christian, See inline.
Thank you. On 23 апр. 2017 г., 18:17 +0300, Christian Hopps <[email protected]>, wrote: > > Alexander Okonnikov <[email protected]> writes: > > > Hi Christian, > > > > See inline. > > > > Thank you. > > > > -- Best regards, Alexander Okonnikov > > > > On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <[email protected]>, wrote: > > > > Alexander Okonnikov <[email protected]> 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? Yes, I has my own experience with migrating IGP for some operator. We migrated from using of single IS-IS instance to multiple instances of IS-IS. As part of migration we was moving IGP links (not IP links themselves) from one instance to another ones. From IGP point of view this is losing and establishing of adjacencies. If other routers trigger RSVP LSP recalculation, their RSVP LSPs would be rerouted around maintained router. Fortunately, the implementation doesn't consider IGP topology changes as a trigger to make RSVP LSPs recalculation, and data plane worked as if there was no IGP maintaining. Notice that re-establishing RSVP LSPs (even with MBB procedure) has some negative effects, like put additional traffic load on some links (detoured traffic), stress CPU on routers, and out-of-ordering (new path is shorter) or delaying (new path is longer) packets. > > > 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. RFC 5443 states that suboptimal IP traffic forwarding is a consequence of using this mechanism. I.e. while we use max-metric to avoid blackholing of traffic on LDP LSPs, we are facing unavoidable side effect in that native IP traffic will be needlessly rerouted as well. If other routers interpret max-metric link as a trigger to resignal RSVP LSPs, drawback of this will impact traffic on latter as well. Thus, max-metric mechanism is multi-purpose and covers several applications. Each time one of applications needs to use 'max-metric', other applications will be impacted as well. > > Thanks, > Chris. > > > > > Thanks, > > Chris.
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
