Hi Christian,
Thank you very much for your detailed review of draft-ietf-ospf-ttz-03. You
made many good observations and your text suggestions also really helped with
the readability and clarity of the I-D. Your review has been discussed at
length with the authors and we hope you will find the new version addresses
your major and minor issues. The list below summarizes your comments, please
find our responses in-line:
[CH] Chris Hops
[HC]: Huaimo Chen on behalf of authors
[CH]
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?
[HC]:
We have revised the definition accordingly in the new version.
[CH]
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."
[HC]:
We have updated the definitions in the new version accordingly.
[CH]
[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?
[HC]:
For a current OSPF transit area with a virtue link, when the cost of
the shortest path for the virtual link changes, the new router LSAs will be
advertised. This is similar to a TTZ regarding to the edge router LSAs being
advertised throughout the area.
[CH]
[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.
[HC]:
We have rephrased/updated the procedure descriptions to clarify the above
in the new I-D.
[CH]
[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?
[HC]:
We have refreshed this section to be clearer in the new version.
[CH]
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.
[HC]:
We have added/updated a few sentences on the motivation in the Introduction
section in the new I-D.
[CH]
[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?
[HC]:
Yes (considered this case in the definition of TTZ edge router in the new
version)
[CH]
[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.
[HC]:
We have changed the text to:
In addition to having similar functions of an OSPF area
[CH]
[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."
[HC]:
We have updated the I-D based on your comments with a few minor adjustments.
[CH]
[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"
[HC]:
Accepted. We have revised the related text based on your suggestions
in the new version.
[CH]
[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.
[HC]:
No. We have added more text to describe them more clearly in the new version.
[CH]
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.
[HC]:
Accepted. We have discussed them separately in the I-D.
[CH]
[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"?
[HC]:
Yes. We have used your text and updated the I-D.
[CH]
[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?
[HC]:
"# links" is the number of (different types of) links that the router LSA
contains. It may be related to the TLV-Length. In an OSPF router LSA
in RFC 2328 (page 206), there is a "length" field as well as this "# links".
[CH]
[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?
[HC]:
Accepted. We have changed flags to options/operations as you suggested and
updated the related parts in the new version.
[CH]
[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.
[HC]:
We have updated the text to be more explicit in the I-D.
[CH]
[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.
[HC]:
Yes, we have added a better definition of the trigger in section 6.4.
[CH]
[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?
[HC]:
In the above case there would be a normal protocol adjacency,
but no TTZ adjacency. Therefore, it would be configuration error on TTZ.
The router LSA by the TTZ edge router is not changed. For the normal
adjacency
between the TTZ edge router A and a non TTZ router B, the router LSA by A
contains the link between A and B. When different TTZ IDs are configured
on the two ends of the link, no TTZ adjacency between A and B is "formed"
and TTZ edge router A will not make any changes on its router LSA.
We have added some additional text in the I-D.
[CH]
[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?
[HC]:
Z==1 indicates that both A and B have migrated to TTZ. In this case,
A sends B all its TTZ LSAs it has and originates its TTZ LSAs. In this case,
no T=1, may have M=1.
"Z==0 and there is a TTZ LSA with T=1" indicates that either A or B is not
migrated to TTZ but advertising TTZ topology information is going on
(indicated by T=1).
In this case, A sends B all its TTZ LSAs it has and originates its TTZ LSAs.
Should not have the case when an adjacency is forming when M=1 instead of
T=1.
M=1 means migrating to TTZ. Before migration to TTZ, all TTZ adjacencies
should
have been discovered/formed. If this case happens (discovering/forming TTZ
adjacency while migrating to TTZ), A sends B all its TTZ LSAs it has and
originates
its TTZ LSAs.
[CH]
[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?
[HC]:
Yes. Good point. We have provided a new figure in section 8.1.
(Discovery of TTZ Neighbors).
[CH]
[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?
[HC]:
When A has been migrated to TTZ and B has not, B should be a new member to
the TTZ to which A belongs (through configuring TTZ on two ends of the link
between A and B), A and other routers in the TTZ have migrated to TTZ.
In this case, A triggers B to migrate to TTZ automatically. Operators may
not
need to trigger B to advertise TTZ topology information or migrate to TTZ
through configurations on B. When receiving M=1 from A, B updates and
advertises its TTZ LSAs and migrate to TTZ.
[CH]
[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."
[HC]:
Agreed. We have updated the I-D accordingly.
[CH]
Does "starts to migrate" here simply means B starts setting it's M=1 as
well?
[HC]:
It means that B starts to compute its routes using the TTZ topology
(i.e., the TTZ LSAs representing the TTZ topology).
[CH]
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?)
[HC]:
B finishes
1) updating and advertising its router LSA if it is TTZ edge router and
2) computing its routes using its TTZ topology.
The TLV with M=1 is removed from the D-LSA.
[CH]
What LSAs are being updated and advertised by B here?
[HC]:
Its normal router LSA and TTZ router LSA if B is a TTZ edge router,
and its TTZ LSAs such as the D-LSA.
[CH]
[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?
[HC]:
Its normal router LSA and TTZ router LSA if A is a TTZ edge router,
and its TTZ LSAs.
[CH]
[section "8.1. Discover TTZ Neighbors" in general]
Are D-LSA sent periodically, if so how often, if not when precisely are they
sent?
[HC]:
When a TTZ-ID is configured on a link, the D-LSA is sent. When there is
a change on the configuration of TTZ-ID, the D-LSA is updated and sent.
D-LSA is sent every 30 minutes by default.
[CH]
What happens when B changes its TTZ ID or doesn't send a D-LSA?
[HC]:
B changes the TTZ-ID in the D-LSA to the new TTZ-ID and sends the D-LSA
when B changes its TTZ ID. Without receiving a D-LSA from B, A will not
"form" TTZ adjacency with B.
[CH]
[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?
[HC]:
Yes. When no TTZ adjacency is "formed" because of the mis-configuration on a
router, an operator can correct the configuration. After the correction,
the TTZ adjacency will be "formed". After TTZ adjacency among a number of
routers have formed, the mis-configured router introduced will not become
TTZ adjacent. After the mis-configuration is corrected, it becomes TTZ
adjacent.
[CH]
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?
[HC]:
A different TTZ ID.
For the routers connected to a broadcast link, after the normal adjacency
among them is formed, the TTZ adjacency may be formed among them. The TTZ
adjacency is formed only if we configure the same TTZ ID on the link on each
of
the routers. If we miss the TTZ ID configuration on any router, the TTZ
adjacency
will not be formed. Thus the DR waits for the receipt of every D-LSA before
deciding to form TTZ adjacency.
[CH]
[section "8.1. Discover TTZ Neighbors" last paragraph]
Is this just saying: "routers only TTZ discover after forming a normal
adjacency"?
[HC]: Yes.
[CH]
[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.]
[HC]:
Accepted. We have added this into the draft accordingly.
[CH]
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?
[HC]:
Mis-configured router will not have TTZ adjacency. It has a normal
adjacency.
The network LSA is advertised within the TTZ and it is not advertised
outside of the TTZ.
[CH]
[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.
[HC]:
Accepted. We have defined it earlier in the new version accordingly.
[CH]
[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?
[HC]:
We have removed this paragraph in the new version.
[CH]
[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?
[HC]:
Agree. We have added some text into the I-D accordingly.
[CH]
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."
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[section: "2. Terminology" 4th item]
Move below 5th item that it references
[HC]:
We have broken the references in the I-D accordingly.
[CH]
[section "4. Requirements" 1st paragraph]
- "*A* Topology-Transparent Zone"
- "for *a* TTZ"
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[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.
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[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."
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[section "6.4. TTZ Options TLV" paragraph 2]
"as needed" => "as described below"?
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[section "6.5. Link Scope TTZ LSA" diagram and paragraph 1]
"Options TLV" => "TTZ Options TLV" (and all other uses?)
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[section "8. Establishing Adjacencies"]
"This section describes the adjacencies in different cases."
=>
"This section describes the TTZ adjacencies."
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[section "8.1. Discover TTZ Neighbors" multiple paragraphs]
"discover TTZ each other" => "TTZ discover each other"
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
[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.
[HC]:
Accepted. We have revised the I-D accordingly.
[CH]
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
...
[HC]:
Accepted. We have updated the I-D accordingly.
[CH]
[section "9.1. Advertisement of LSAs within TTZ" paragraph 1]
"advertised within" => "advertised only within"
[HC]:
Accepted. We have changed the I-D accordingly.
[CH]
[section "11.1. Configuring TTZ" last paragraph]
"the above one" => "option 1"
[HC]:
Accepted. We have updated the I-D accordingly.
[CH]
[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."
[HC]:
Accepted. We have updated the I-D accordingly.
[CH]
[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."
[HC]:
Accepted. We have updated the I-D accordingly.
[CH]
[section "12.2. Implementation Experience"]
Convert IETF 90 to (or include) a date.
[HC]:
Accepted. We have updated the I-D accordingly.
[CH]
[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.
[HC]:
We did include an IANA section and suggested a registry value of 9.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
