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 LSA by adding a point-to-point link to each of the other known edge routers in the TTZ, and also by adding the stub links advertised by TTZ internal routers. Step 2: After RMaxLSAAdvTime (.1 seconds) or MaxLSAGenAdvTime (.3 seconds) remove the TTZ links from its router LSA. [section "10. Computation of Routing Table" The text says to ignore *all* links from a TTZ edge routers router LSA. This presumably works b/c the SPF is also going to use the advertised TTZ Router LSA instead. Shouldn't the fact that the SPF should using the new TTZ Router LSA be stated somewhere as well? Minor Issues: ============= [section: "Introduction" 2nd paragraph] The initial sentence makes an assertion about complexity and time consumption for area creation. The following sentence does not back this assertion up but merely describes the act of creating a new area. I found this less than compelling. [section: "2. Terminology"] This need not be addressed here but it's where I had the question: Can a TTZ edge router be in more than one TTZ? [section "5.1. Overview of Topology-Transparent Zone" 3rd paragraph ] "In addition to having the functions of an OSPF area", is this actually the case? That is, is a TTZ really a superset of OSPF area functionality? I'm pretty sure it is not. [section "5.1. Overview of Topology-Transparent Zone" Bullet 1] "o An OSPF TTZ is virtualized as the TTZ edges connected each other." This is a very important bullet as it actually will describe what a TTZ really is. As such I'd suggest more precise text here. For example: "o An OSPF TTZ represents a set of TTZ internal routers as a full mesh of virtual links between the TTZ edge routers." ? [section "5.1. Overview of Topology-Transparent Zone" Bullet 2] "An OSPF TTZ receives the link state information about the topology outside of the TTZ, stores the information in the TTZ and floods the information through the TTZ to the routers outside of the TTZ." This bullet is a bit clunky to read. Perhaps something more direct like: "Non-TTZ link state information is handled as normal (i.e., it is not filtered or modified by a TTZ)" If you want to keep the original text then a couple nits: "An OSPF TTZ receives" => "TTZ Routers receive" "stores the information in the TTZ and floods" => "store the information, and flood" [section: "6.1. General Format of TTZ LSA" paragraph 3] "A TTZ LSA having an optional TTZ Router TLV is called a TTZ Router LSA. A TTZ LSA containing a TTZ Options TLV is called a TTZ Control LSA." Can these ever be combined? By naming them distinctly like this, it seems to be exclusive, if this is the case that should probably be more clearly defined. In general I think more expansion and clarity here is in order. Instead of talking about LS Type 10/9 with a note about type 10. Why not discuss each type: - LS Type 9 "Link local scope" when it is used, and what is optional and mandatory in it. - LS Type 10 "Area scope" when it is used, and what is optional and mandatory in it. [section "6.3. TTZ Router TLV" paragraph 1] "The format of a TTZ Router TLV is as follows. It contains the contents of a router LSA." Is this trying to say: "It has the same content as a standard OSPF Router LSA (RFC x-ref) with the following modifications"? [section "6.3. TTZ Router TLV" TLV content] Given the existence of the TLV-Length, is the "# links" field redundant? What happens if they correctly correlate? [section "6.4. TTZ Options TLV" "flags"] So "exclusive" => "mutually exclusive"? If this is the case these aren't really flags but rather one of 4 possible values (I believe in the all 0 case the TLV is not advertised?), and if so it would be much better to simply define the 4 possible values using 2 bits. What happens if more than one bit is set to 1? [section "7. Constructing LSAs for TTZ" paragraph 3] This text can be read to indicate that for TTZ internal routers the router's normal Router LSA content is copied into a TTZ Router TLV, does the router also advertise its Router LSA as normal or is that then suppressed? It's not clear to me why this information needs copying, and so I'm wondering if the text is saying that no TTZ Router TLV is included, and that the TTZ internal router just advertises it's regular OSPF Router LSA. The text could be more explicit. Also some of my confusion stems from earlier defining a "TTZ Router LSA" as one containing an "optional TTZ Router TLV". So when the text here refers to the LSA as a TTZ Router LSA one might assume that the optional TTZ Router TLV must be present. Perhaps this gets back to my want for better separating and defining the LS Types and contents. [section "7. Constructing LSAs for TTZ" paragraph 4 and 9] "After receiving a trigger to migrate to TTZ such as a TTZ LSA with flag M = 1, a TTZ edge router originates its normal router LSA for virtualizing a TTZ, which comprises three groups of links in general." "To roll back from a TTZ smoothly after receiving a trigger to roll back from TTZ, ..." - Triggers are mentioned a few times throughout the text. I think the triggers meaning, rather than being initially implied, should be explicit defined early and in 1 location. It isn't until section 11.2 that I thought I understood what triggers were and how they worked. Actually the triggers are defined in section 6.4, but the text there never actually uses the word "trigger". I suggest that this be changed so that it is clear what a trigger is prior to the use of the term. [section "8.1. Discover TTZ Neighbors" paragraph 2] "If two ends of the link have different TTZ IDs, no TTZ adjacency over the link will be "formed"." - In general I'm somewhat confused about the actual definition of a TTZ adjacency. How does it compare to a normal protocol adjacency. In the above case you would have a protocol adjacency I believe, but no TTZ adjacency? How is this link advertised if the router is a TTZ edge router? [section "8.1. Discover TTZ Neighbors" paragraph 5] The text talks about when (Z==0 and there is a TTZ LSA with T=1) or Z==1. Where are all the places that T=1 is showing up? What about the case when an adjacency is forming when M=1 instead of T=1? [section "8.1. Discover TTZ Neighbors" paragraph 7] Since the diagram state Zs are the same, it no longer applies to the rest of section 8. Is it worthwhile to have a new diagram here for clarity? [section "8.1. Discover TTZ Neighbors" paragraph 8] Here's a mention of "triggers B to migrate", I think you probably should state explicitly what this means, which I *think* is: "A also sends a D-LSA containing a TTZ Control TLV with M=1 to B, triggering it to migrate." Although this now makes me wonder what does B do on receiving M=1 if it had not received or been configured for T=1 yet? [section "8.1. Discover TTZ Neighbors" paragraph 9] I would break this paragraph up to make clear that 2 distinct things are happening based on 2 different events. So: "When B receives the D-LSA from A and determines they have the same TTZ ID but its Z=0 and A's Z=1, B sends A all the TTZ LSAs it has and starts to migrate to TTZ after receiving A's D-LSA with M=1. After migration to TTZ, B updates and advertises its LSAs as needed." becomes: "When B receives the D-LSA from A and determines they have the same TTZ ID but its Z=0 and A's Z=1, B sends A all the TTZ LSAs it has." "When B receives the D-LSA from A with M=1 it starts to migrate to TTZ. After migration to TTZ, B updates and advertises its LSAs as needed." Does "starts to migrate" here simply means B starts setting it's M=1 as well? What exactly is happening for B to go from "starts to migrate" to "After migration"? I believe this is indicated by Z=0 transitioning to Z=1 (is the TTZ Control TLV with M=1 also removed from the D-LSA?) What LSAs are being updated and advertised by B here? [section "8.1. Discover TTZ Neighbors" paragraph 10] "After receiving B's D-LSA with Z=1, A updates and sends B its D-LSA by removing the Options TLV. It also updates and advertises its LSAs as needed." What LSAs are being updated and advertised by A here? [section "8.1. Discover TTZ Neighbors" in general] Are D-LSA sent periodically, if so how often, if not when precisely are they sent? What happens when B changes its TTZ ID or doesn't send a D-LSA? [section "8.1. Discover TTZ Neighbors" Broadcast and NBMA part (i.e., paragraph 11+)] [section "8.1. Discover TTZ Neighbors" paragraph 12] So the mis-configured router behavior is dependent on when the mis-configured router is introduced? If introduced prior to any adjacency formation then its presence will keep all routers from becoming TTZ adjacent, otherwise only itself will not have become TTZ adjacent? What does mis-configured mean, a different TTZ ID? What about the lack of the receipt of a D-LSA on the link? How long does the DR wait for receipt of a D-LSA from each neighbor before deciding it won't be receiving one and the neighbor is not configured on this link as part of TTZ? [section "8.1. Discover TTZ Neighbors" last paragraph] Is this just saying: "routers only TTZ discover after forming a normal adjacency"? [section "9.1. Advertisement of LSAs within TTZ" paragraph 2] "Any network LSA generated for a broadcast or NBMA network in a TTZ is advertised within the TTZ." [nit: And not outside? This is explicit for the router LSA.] What happens when a DR has a mis-configured router on a broadcast network and thus is not forming a TTZ adjacency with it? It still has a normal adjacency right? So it no has a network LSA that includes both TTZ and non-TTZ routers where does it advertise this network LSA? [section "11.2. Smooth Migration to TTZ" paragraph 5] I was confused by many mentions earlier in the document to a router migrating to a TTZ. I think what paragraph 5 in section 11.2 is saying (in too many words) is this: "Migrating to a TTZ" means a router advertises a TTZ Control TLV with M=1. A router "Migrates to a TTZ" either when configured to do so or when it receives a TTZ Control TLV with M=1. If this is the case then I think something like the above text should occur earlier in the document. [section "11.3. Adding a Router into TTZ" paragraph 3] I don't understand the intent of this paragraph. Is it just saying that if TTZ is configured on a link between 2 non-adjacent routers, when they eventually become adjacent they will also form a TTZ adjacency? [section "13. Security Considerations"] This seems a bit weak or perhaps just wrong. Perhaps better would be to say that TTZ relies on the OSPF security mechanisms in place and has the same security threat surface? Nits: ===== [section: "2. Terminology" 3rd item] "TTZ external router: a router outside of a TTZ without any TTZ internal link." => "TTZ external router: a router outside of a TTZ that has no TTZ internal links." [section: "2. Terminology" 4th item] Move below 5th item that it references [section "4. Requirements" 1st paragraph] - "*A* Topology-Transparent Zone" - "for *a* TTZ" [section "5.1. Overview of Topology-Transparent Zone" 1st paragraph ] Define and use TTZ ID, rather than just "(ID)" as that is what the rest of the document refers to this as, and is more specific anyway. [section "5.2. Some Details on TTZ" paragraph 4] "Note that none of the TTZ internal routers can be an ABR." => "Note that by definition a TTZ internal router cannot also be an ABR." [section "6.4. TTZ Options TLV" paragraph 2] "as needed" => "as described below"? [section "6.5. Link Scope TTZ LSA" diagram and paragraph 1] "Options TLV" => "TTZ Options TLV" (and all other uses?) [section "8. Establishing Adjacencies"] "This section describes the adjacencies in different cases." => "This section describes the TTZ adjacencies." [section "8.1. Discover TTZ Neighbors" multiple paragraphs] "discover TTZ each other" => "TTZ discover each other" [various section "8.1. Discover TTZ Neighbors" ...] Text uses = and == but in both cases it means equality check, not assignment, pick and use one consistently in the document. On the use of parenthesis, the text is using parenthesis as a form of grouping as one might in mathematics which I'm not sure is proper. Parenthesis in writing are generally used as an aside. Probably the clearest way to indicate the logical grouping would be to use a list, e.g., When one of the following conditions is met. - Z = 0 and there is a TTZ Options LSA with T = 1 - Z = 1 ... [section "9.1. Advertisement of LSAs within TTZ" paragraph 1] "advertised within" => "advertised only within" [section "11.1. Configuring TTZ" last paragraph] "the above one" => "option 1" [section "11.3. Adding a Router into TTZ" paragraph 1] "When a non TTZ router (say R1) is connected via a P2P link to a TTZ router (say T1) working as TTZ and there is a normal adjacency between them over the link, a user can configure TTZ on two ends of the link to add R1 into the TTZ to which T1 belongs. They discover TTZ each other with the TTZ as described in section 8." => "When a non TTZ router (say R1) is connected via a P2P link to a migrated TTZ router (say T1), and there is a normal adjacency between them over the link, a user can configure TTZ on both ends of the link to add R1 into the TTZ to which T1 belongs. They TTZ discover each other as described in section 8." [section "11.3. Adding a Router into TTZ" paragraph 2] "When a number of non TTZ routers are connected via a broadcast link to a TTZ router (say T1) working as TTZ and there are normal adjacencies among them, a user configures TTZ on the connection to the link on every router to add the non TTZ routers into the TTZ to which T1 belongs. The DR for the link "forms" TTZ adjacencies with the other routers connected to the link if they all have the same TTZ ID configured for the link. This is determined through the discovery process described in section 8." => "When non TTZ routers are connected via a broadcast or NBMA link to a migrated TTZ router (say T1), and there are normal adjacencies among them, a user configures TTZ on the connection to the link on every router to add the non TTZ routers into the TTZ to which T1 belongs. The DR for the link "forms" TTZ adjacencies with the other routers connected to the link if they all have the same TTZ ID configured for the link. This is determined through the TTZ discovery process described in section 8." [section "12.2. Implementation Experience"] Convert IETF 90 to (or include) a date. [section "14. IANA Considerations"] While not requested in the text, a new registry needs to be created for the management of TTZ TLV types and so information regarding this new registry in addition to the initial seed values is required. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail