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
