[OSPF] RtgDir review: draft-ietf-ospf-ttz-03
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-ttz-03 Reviewer: Christian Hopps Review Date: April 26, 2016 IETF LC End Date: unknown Intended Status: Experimental Summary: I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: = While I believe that the document is for the most part readable and understandable, I believe it still requires better or more definitions, clarifications, and/or additional text before becoming an RFC. Major Issues: = [section "2. Terminology"] - An edge router is defined as a router with internal and external adjacencies. (and referred to this way later in the text as well). Is this the actual definition or is it instead when a router has links that are and are not configured as TTZ internal? This makes a big difference b/c the former case is very dynamic while the latter is static. One could imagine in the former case that a router is configured to be within a TTZ and then by virtue of who it becomes adjacent with determines whether it is internal or edge. While this makes configuration very simple I think it also has a big impact on the complexity of the protocol interactions. After reading section 11.1 "Configuring TTZ" which proposes "some options for configuring a TTZ", it certainly seems that the intention is for links to be determined to be within a TTZ or not based only on configuration. If this is indeed the case I think this needs to be stated up front and very clearly, and I would suggest changing all the text in "2. Terminology" to talk about configuration instead of adjacencies. For example: "TTZ link or TTZ internal link: a link configured to be inside the TTZ." "TTZ external link: a link not configured to be within a TTZ" "TTZ internal router: a router configured with only TTZ internal links." "TTZ external router: a router with no configured TTZ internal links" "TTZ edge router: a router configured with both TTZ internal and TTZ external links." [section "7. Constructing LSAs for TTZ" paragraph 6 and 7] ... "The cost of the link is the cost of the shortest path from this TTZ edge router to the other TTZ edge router within the TTZ." "In addition, the LSA may contain a third group of links, which are the stub links for the loopback addresses inside the TTZ to be accessed by nodes outside of the TTZ." - So basically every SPF from a TTZ internal topology change can lead to new edge router LSAs being advertised throughout the area to adjust the "virtual" routing link costs. This is noteworthy because while you've hidden state using the TTZ, the dynamics of the network haven't gotten simpler rather they've gotten more complex, as changes are now cascading rather than being singular. This is an interesting trade-off choosing perpetual run-time and protocol complexity in order to avoid the one time cost of new area creation. Would it be worth actually pointing out these costs of using TTZ? [section "7. Constructing LSAs for TTZ" paragraph 8] "To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ in two steps. At first, the router updates its normal router LSA by adding a point-to-point link to each of the other edge routers of the TTZ and a stub link for each of the loopback addresses in the TTZ to be accessed outside of the TTZ into the LSA. And then it removes the links configured as TTZ links from its updated router LSA after sending its updated router LSA and receiving the updated router LSAs originated by the other TTZ edge routers for MaxLSAAdvTime or after sending its updated router LSA for MaxLSAGenAdvTime (refer to Appendix A)." In order to be sure I understood this I basically broke it apart and put it together again with possibly incorrect reductions. I ended up with: To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ in two steps: Step 1: The router updates its router L
Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
Alexander Okonnikov 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
Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
Alexander Okonnikov writes: > Hi Christian, > > See inline. > > Thank you. > > -- Best regards, Alexander Okonnikov > > On 21 апр. 2017 г., 18:36 +0300, Christian Hopps , wrote: > > Alexander Okonnikov 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. signature.asc Description: PGP signature ___ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
[OSPF] IS-IS and OSPF Call for agenda slots @ IETF-100
Hi OSPF and IS-IS, The preliminary agenda has been posted: https://datatracker.ietf.org/meeting/100/agenda.html Our 2.5h joint session of IS-IS and OSPF is tentatively scheduled for Thursday from 9:30am to 12:00pm (+08). Please send your requests for a presentation slot, indicating draft name, speaker, and desired duration (covering presentation and discussion) to isis-cha...@ietf.org or ospf-cha...@ietf.org. Thanks, Abhay, Acee, Chris and Hannes. signature.asc Description: PGP signature ___ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
Re: [OSPF] IS-IS and OSPF Call for agenda slots @ IETF-100
Acee Lindem (acee) writes: > Hi Chris, et al, > > The authors of "OSPF Graceful Restart Enhancements”, > draft-basavaraj-ospf-graceful-restart-enhancements-00 would like a 10 > minute slot at IETF 100. ACK. Who's presenting? Thanks, Chris. > > Thanks, > Acee > > > On 10/19/17, 9:55 AM, "Christian Hopps" wrote: > >> >>Hi OSPF and IS-IS, >> >>The preliminary agenda has been posted: >> >> https://datatracker.ietf.org/meeting/100/agenda.html >> >>Our 2.5h joint session of IS-IS and OSPF is tentatively scheduled for >>Thursday from 9:30am to 12:00pm (+08). >> >>Please send your requests for a presentation slot, indicating >>draft name, speaker, and desired duration (covering presentation and >>discussion) to isis-cha...@ietf.org or ospf-cha...@ietf.org. >> >>Thanks, >>Abhay, Acee, Chris and Hannes. ___ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
[OSPF] Call for agenda topics for LSR @ IETF-101 (a.k.a. IS-IS and OSPF :)
Hi Folks, The newly forming LSR (link-state-routing) WG will be meeting on Wednesday March 21, 2018 from 9:30 to 12:00. Please send us (lsr-cha...@ietf.org) any requests for presentation slots. Currently we have 1 slot request: - https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/ https://datatracker.ietf.org/doc/draft-li-dynamic-flooding-isis/ Thanks, Chris & Acee. ___ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
