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 <bit>=<value> and <bit>==<value> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
