Hi Huaimo, Thank you for the updated draft that addresses my comments.
I am concerned about the attack vector that the op-code migration opens, but at least it is documented and this is experimental. I will move this to IETF Last Call and place it on the IESG telechat for January 5. Regards, Alia On Tue, Dec 13, 2016 at 8:48 PM, Huaimo Chen <[email protected]> wrote: > Hi Alia, > > > > Thank you very much for your detailed review of > draft-ietf-ospf-ttz-04. Your review has been discussed with the authors > and we hope you will find the new version addresses your major or minor > issues. Please find our responses in-line below: > > > > [HC]: Huaimo Chen on behalf of authors > > > > > > > As is customary, I have done my AD review of draft-ietf-ospf-ttz-04. > First, I would like to thank the authors, Huaimo, Renwei, Alvaro, Yi, Vic, > & Mehmet, as well as the contributors & the WG for their work on this > document. > > > > > > With this number of authors, it is necessary to either select a small > number of editors or provide significant justification for how each author > has contributed to the document. > > > > [HC]: The original idea of TTZ draft is from Renwei and Huaimo. Alvaro has > made significant contributions to TTZ draft, including TTZ configurations, > migrations to TTZ and rolling back from TTZ, and definitions of some data > formats. Yi has contributed to constructing LSAs for TTZ and discovery of > TTZ neighbors. Vic and Mehmet have contributed to the requirements and > operations on TTZ. Vic made a good presentation on TTZ in IETF and answered > some questions about TTZ. > > > > > > > The draft cannot proceed to IETF Last Call until that is done. > > > > > > In my review below, I have found a number of issues with this > document. Several are significant enough technical concerns that may add > non-trivial text to the draft and thus require addressing before IETF Last > Call. > > > > > > If these issues are addressed with an updated document by Dec 15, it is > possible that the draft could make the Jan 5 IESG telechat. > > > > > > 1) Please clarify somewhere in the introduction that this is only for > OSPFv2. > > > > [HC]: In the introduction, "... extensions to OSPFv2 ..." is stated. > > > > > > > 2) In Sec 6.1: Replace the TTZ-LSA-Type (9) with TTZ-LSA-Type (TBD). > It's unfortunate that an early allocation wasn't done, but if you want to > suggest a value for the allocation, that should be in the IANA > considerations section. > > > Remove the sentence "Where TTZ-LSA-Type is 9, the exact number is to be > assigned by IANA." > > > > [HC]: Replaced "TTZ-LSA-Type (9)" with "TTZ-LSA-Type (TBD)" and > > removed "Where TTZ-LSA-Type is 9, the exact number is to be assigned by > IANA." > > > > > > > 3) In Sec 6.2: Please specify what the TLV-Length is. Please specify > what a TTZ ID is in the text; what are valid values? What are the concerns > for allocation? What is the uniqueness? I assume that it is an arbitrary > non-zero value that is specified by configuration on a TTZ Router & needs > to be unique in the OSPF network. Can a TTZ router have only one TTZ ID? > > > > [HC]: Added specification on the TLV-Length, and > > more details on TTZ ID in Sec 5.1 and Sec 11.1, which should answer these > questions. > > > > > > > "It sets flag Z to 1 after it has migrated to TTZ." Please clarify - > how long is flag Z set? When is flag Z cleared? I see some details in Sec > 6.4 - please at least add a forward reference as well as indicating when > flag Z is cleared. > > > > [HC]: Added text about when flag Z is set to 0 and reference to Sec 6.4. > > > > > > > 4) Sec 6.3: The reference for Link Type for IANA is [RFC 4940]. > Please clarify that while the Link Type field is 8 bits, the values 128-255 > are reserved, which allows this reuse of the bottom 7 bits. > > > > [HC]: Added reference and clarification accordingly as you suggested. > > > > > > > 5) Sec 6.4: "When another TTZ router receives the LSA > > > with OP for T, it originates its TTZ LSA as described below. > > > > > > Migrating to TTZ (M): After a user configures a TTZ router to migrate > > > to TTZ, migrating to TTZ is triggered." > > > > > > The first sentence contradicts the second. I think the first is saying > that when a TTZ router receives a new TTZ Router LSA from its neighbor, the > receiving TTZ router starts migrating - but the second sentence states that > the migration only happens on configuration. Please clarify the actual > behavior. > > > > [HC]: Changed the first sentence to disconnect it from the second one. > > They are not directly related. > > > > > "For a TTZ internal router, it also updates its TTZ indication LSA > > > with Z = 1. For a TTZ edge router, it updates its TTZ router LSA > > > with Z = 1 and its router LSA for virtualizing the TTZ." > > > I assume that a TTZ router determines whether it is internal or external > based > > > upon how its links are configured instead of any learned data? Please > explicitly > > > state how this is done. > > > > [HC]: Explicitly stated that it is based on configurations. > > > > > > > " When another TTZ router receives the LSA with OP for N, it > advertises its > > > normal LSAs and stops advertising its TTZ LSAs." > > > Does that TTZ router also originate new TTZ Control LSA so the change > spreads? > > > Please clarify whether "stops advertising its TTZ LSAs" includes the TTZ > Control LSA > > > that it just originated? I assume not - but a literal reading of the > text doesn't tell. > > > > [HC]: The receiving TTZ router does not originate a new TTZ control LSA. > > It forwards/floods the LSA with OP for N. > > Added "it forwards the LSA" after receiving the LSA. > > The LSA means the TTZ control LSA. > > This may help clarify "stops advertising its TTZ LSAs" not include > > the TTZ control LSA received. > > > > > " Rolling back from TTZ (R): After a user configures a TTZ router to > > > roll back from TTZ, rolling back from TTZ is triggered. The TTZ > > > router originates a TTZ Control LSA having a TTZ Options TLV with OP > > > for R and rolls back from TTZ. When another TTZ router receives the > > > LSA with OP for R, it also rolls back from TTZ." > > > > > > What if the TTZ router (call it X) that receives the LSA with OP=R > hasn't already gotten > > > an LSA with OP=N so X isn't advertizing its normal LSAs nor has it > stopped advertising its > > > other TTZ LSAs? > > > > [HC]: Operators should follow a correct sequence of operations: > > At first, configure to advertise normal LSAs and stop advertising TTZ LSAs. > > And then configure to roll back from TTZ. > > Some details are added in Sec 11.2 (around the end of Sec 11.2) to > describe what happens > > in the case you mentioned. > > > > > > > 6) Sec 7.1: "also by adding the stub links for the loopback addresses > in the TTZ to > > > be accessed outside of the TTZ." > > > How does a TTZ Edge Router determine set of loopback addresses in the > TTZ to be advertised? > > > I don't see a clear way for a TTZ Internal Router to indicate that. > > > > [HC]: Added "according to configuration policy of operators" > > to indicate that the loopback addresses are determined based > > on configurations. > > > > > > > 7) Sec 8.1 " If two ends of the link have different TTZ IDs or only > one end is > > > configured with TTZ ID, no TTZ adjacency over the link will be > > > "formed"." > > > Can a TTZ router have multiple TTZ IDs? Are the TTZ IDs per router? > Is it possible to migrate from one TTZ ID to > > > another TTZ ID without migrating away from TTZ, configuring all the > future-TTZ routers, > > > and then migrating back to TTZ? Please clarify such as "A router > MUST use at most one TTZ ID. > > > If multiple LSA D-LSAs are received from a neighbor with different > TTZ IDs, then no TTZ adjacency > > > will be formed even if one of the TTZ IDs match" or perhaps a TTZ > adjacency is formed?? Maybe the > > > lowest TTZ ID is used. The real point is to be extremely clear on > the mandatory behavior. > > > > [HC]: A TTZ router can have multiple TTZ IDs on its multiple links, > > each of which has a different TTZ ID. TTZ ID is per link. > > The usage of TTZ IDs are added and clarified in Sec 11.1. > > In current extensions to OSPFv2, we can not migrate from > > one TTZ ID to another TTZ ID without migrating away from TTZ. > > One TTZ with a TTZ ID can be roll/migrate back to a part of area, > > and then migrate to another TTZ with another TTZ ID. > > Multiple D-LSAs are received one after another. > > When one of the D-LSAs is received from a neighbor with > > same TTZ ID, a TTZ adjacency is formed. > > When another D-LSA is received from the same neighbor with > > different TTZ ID, the TTZ adjacency is removed. > > Revised Sec 8.1 using conformance language. > > > > > > > " D-LSA is not received for sometime such as 60 minutes or is > > > flushed." There needs to be a specific MUST description - for > instance. > > > "If the D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or > is explicitly flushed, then the TTZ adjacency MUST be > > > removed. The D-LSA-MAX-RETRANSMIT-TIME SHOULD be set to 60 minutes, > but MAY be configurable." > > > > [HC]: Changed the text according to your suggestion. > > > > > > > 8) Sec 9.1: The advertisement rules make sense, but it would be more > helpful to indicate HOW the TTZ Edge Router determines that an LSA is about > a TTZ internal resource. For instance, before advertising a Router LSA to > a non-TTZ neighbor, the TTZ Edge Router should determine that it does not > have a matching TTZ Router LSA. As far as I can tell, a TTZ Internal > Router advertises both a Router LSA and a TTZ Router LSA - where the Router > LSA is suppressed by the TTZ Edge Routers?? By being clear on how a TTZ > Edge Router can make the decision, you avoid questions on race conditions > during migration and different misinterpretations. > > > > [HC]: Added descriptions about how the TTZ Edge Router > > determines that an LSA is about a TTZ internal link state. > > A TTZ internal router advertises a router LSA and > > a TTZ indication LSA, which indicating the router LSA > > is about a TTZ internal link state. > > > > > > > 9) Sec 10: This section implies that a TTZ Edge Router originates a TTZ > Router LSA that contains both TTZ-external and TTZ-internal links - and > that TTZ Router LSA is different from the Router LSA that is generated. In > Sec 7, "For a TTZ edge router, its normal Router LSA content is copied into > a TTZ Router TLV with the modifications described in section 6, and a TTZ > router LSA containing this TLV is constructed and advertised." but Section > 7.1 describes how the TTZ Edge Router changes its normal Router LSA. I > think you need to clarify in both Sec 7 and Sec 7.1 exactly what is in the > TTZ Edge Router's TTZ Router LSA. I can conclude that it has to be the > Router LSA for the TTZ Edge Router as if no TTZ were configured - but that > isn't said that the contradiction between Sec 6 & Sec 7.1 can cause > confusion. > > > > [HC]: Updated the text in Sec 7 to clarify. > > > > > > > "This can be achieved by adding a flag into every link stored in LSDB and > > > setting this flag to 1 in every link in these router LSAs, which > > > indicates that the link is unusable. It computes routes using the > > > TTZ topology (i.e., using LSAs for representing the TTZ) and the > > > topology outside of the TTZ, excluding any unusable links." > > > This sounds like a very inefficient way. Why wouldn't a router simply > use the > > > TTZ Router LSA for every TTZ Router and the regular Router LSA if the > originating > > > router didn't also originate a TTZ Router LSA? > > > > [HC]: The implementation is removed. > > The idea you described will work. > > > > > > > 10) Sec 11.1: This implies that a router can have different TTZ IDs on > its different links. Is that the case?!? > > > Consider the case where there is a router X with the following: > > > link X.1 TTZ ID = none > > > link X.2 TTZ ID = 10 router Y is another edge router > in TTZ 10 > > > link X.3 TTZ ID = 20 router Z is another edge router > in TTZ 20 > > > > > > Now, when X advertises its Router LSA, it will advertise X.1, > virtual-TTZ-ID-10.to_Y, and virtual-TTZ-ID-20.to_Z. > > > I don't know what X puts into its TTZ Router LSA for TTZ ID=10 or > ID=20. I guess it would originate > > > X.1, virtual-TTZ-ID-10.to_Y and X.3 for TTZ-ID=20 and > > > X.1, X.2, virtual-TTZ-ID-20.to_Z for TTZ-ID=10 > > > I think it could be made to work, but there's some missing text if this > is a real case. I suspect what you want is: > > > "If one link of a router is configured with a particular TTZ ID, other > links of that router can either have no TTZ ID > > > or have the same particular TTZ ID. Two links of the same router MUST > NOT have different TTZ IDs configured." > > > > [HC]: Yes. That is the case. > > Added the missing text accordingly. > > > > > > > 11) Sec 11.2: "a user issues a CLI command on one router in the TTZ" > How about configures instead of CLI command? > > > We are heading towards a brave new world of NetConf. > > > > > > " Thirdly, a user checks whether a router in the TTZ is ready for > > > migration to TTZ. A router in the TTZ is ready after it has received > > > all the necessary information from all the routers in the TTZ. This > > > information may be displayed on a router through a CLI command." > > > All necessary information isn't descriptive or useful! Please be > specific. > > > I think what is needed is to have received the TTZ Router LSAs from all > > > TTZ Edge Routers. This check depends upon the operator, since which > > > routers are TTZ Edge Routers depends on the intended network topology > > > and not a specific router's configuration. > > > > > > bottom of p. 19 "For rolling back from TTZ, it is similar.": > > > This is a normative specification. PLEASE specify it exactly. > > > > > > " After a router receives a TTZ LSA with OP for M for 3) from another > > > router, it checks whether 2) is performed through checking if it has > > > received/originated TTZ LSAs. If it has not, it issues an error and > > > logs the error. The operation for migration will continue." > > > > > > What is meant by "the operation for migration will continue". PLEASE be > > > extremely clear and detailed in the document. I first read it as > meaning that the rest of the network would continue to do the migration - > since other routers are getting the TTZ LSA OP=M. That would, of course, > strand the unmigrated router. > > > > [HC]: Changed CLI command to configuration or configure > > according to your suggestion. > > Updated the text to be more specific. > > Replaced "For rolling back from TTZ, it is similar." with > > detailed descriptions on correct sequence of operations > > for rolling back from TTZ. > > Revised the paragraph with specific specification and details. > > > > > > > 12) Sec 13: The implementation experience is good to see, but please > remove personal judgments > > > like "easy" and straightforward". Normally the implementation > experience section is removed from > > > internet-drafts when they > > > are published as an RFC. Please move Sec 13 to an Appendix with a > suitable > > > note to the RFC Editor for removal. If you strongly want to leave it > in, we can discuss additional clean-up. > > > > > > Just FYI for the future, this would be even more helpful if any of the > error paths or failure cases and race conditions were examined and tested. > > > > [HC]: Removed personal judgments as you suggested. > > Moved Sec 13 to an Appendix. > > > > > > > 13) Sec 14: "The mechanism described in this document does not raise > any new > > > security issues for the OSPF protocols since a TTZ is enclosed in a > > > single area." Depending on the failure behavior I asked about in > (11), you might > > > have introduced the ability to cause at least all TTZ internal routers > to be isolated and stranded if one malicious router sends a TTZ LSA with > OP=R into a running TTZ. I'm not positive that you don't have a similar > scenario for OP=M; that case needs to be thought through - you may just end > up with isolated regions of routers. > > > > > > At a minimum, something that prevents injection attacks is really > important, given these issues. > > > > [HC]: Added something accordingly as you suggested. > > > > > > > 14) Appendix A: Please move this into the main draft and use normative > language and indicate whether these are fixed constants or subject to > configuration. I will note that 0.1 seconds is only 100 ms and whether it > is practical can depend upon the propagation delay within the area. > > > > [HC]: Updated the main draft accordingly as you suggested. > > > > > > Regards, > > Alia >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
