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.
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.
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."
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?
"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.
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.
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.
"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.
" 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.
" 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?
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.
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.
" 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."
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.
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.
"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?
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."
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.
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.
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.
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.
Regards,
Alia
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
