Comments on draft-ietf-ospf-mt-ospfv3-00

[Alan Davey <[e-mail]>]

Folks

I have read the draft-ietf-ospf-mt-ospfv3-00 and I have some doubts and
questions.  I have listed these below, together with some minor
editorial nits that I noticed as I went through the draft. 

Please let me know your thoughts.

Regards
Alan

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   [phone]
Fax:   [phone]
Email: [e-mail]
Web:   http://www.dataconnection.com


Comments and Doubts
-------------------

1.  I think that the draft probably requires an "IANA considerations"
section.  You may need to request a new address space for the MT values.
You may also need to request a space for TLV and sub-TLV type values.

2.  Currently, the scope of the TLV types is restricted to the
containing LSA.  I wonder if having globally unique TLV types would
simplify code, for example, for protocol analysis.

3.  I have some doubts about the S-bit in the value field of TLVs to
indicate the presence of sub-TLVs.

-  I am not convinced that the S-bit is necessary; an implementation
either recognizes a TLV type or it does not.  In my opinion, if the
implementation recognizes the TLV then it knows if sub-TLVs are present.
If the implementation does not recognize the TLV type then the TLV is
ignored.  Either way, the S-bit does not appear to be necessary.

-  I may be misinterpreting the draft, but it appears to be inconsistent
in its specification of the use of the S-bit.  Section 6 states that the
S-bit is set in the value field of TLVs.  However, 

	o	the extended LSA formats in section 20 do not define the
S-bit.  For example, in section 20.1, the extended Router-LSA LD-TLV has
sub-TLVs defined but the S-bit does not appear in the definition of the
LD-TLV.

	o	section 20.1 defines a Router Multi-Topology *sub-TLV*
with an S-bit shown.  What is the purpose of the S-bit in the sub-TLV?

4.  I also have doubts as to whether the "Total sub-TLV length" field
defined in section 6. is needed.  I think that

-  an implementation can use the sub-TLV length fields to skip to the
next value
-  the "Total sub-TLV length" is only useful if there are multiple
sub-TLVs that an implementation does not process.

5.  I am confused over whether the default topology MUST be defined
using non-extended LSAs or if it MAY be defined using extended LSAs.

-  Section 7. states that "In order to interact with non-MT capable
routers we define default topology as the topology that is built by
using the existing LSAs as specified in OSPFv3 [OSPFv3]."

-  Section 8. states that "When a MT capable router participates in
Default Topology, depending on RFC2740Compatibility (see Appendix A) it
will generate existing LSAs or extended LSAs for the Default Topology."

I suggest removing the first paragraph of Section 7.

6.  Section 11., paragraph 2 states that "(and all routers should be MT
capable)".  I think that this should be "MUST be MT capable".

7.  Section 20.1 states the following.

	We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This
sub-TLV could further contain sub-TLVs.

I think that it may be better to define the RMT-sTLV without the
possibility of further sub-TLVs.  If future extensions are required then
they can be added as separate sub-TLVs of the LD-TLV.

8.  Section 20.5 states the following.

	Note that when the sub-TLV is present (S-bit set in the
PrefixOptions) the 
	sub-TLV is placed after Forwarding address and external route
Tag if they are present.

I think that it is not possible to tell if the Forwarding address and
external route Tag are present if a sub-TLV is placed inside the
EMT-TLV.  

Better to define the MT-TLV as not having any sub-TLVs.  Any future
additions can be made as separate TLVs.

Questions
---------

1.  Do you expect any new LSAs defined in the future to have the T-bit
set in the LS type field?

2.  Can passive interfaces be configured on a per-MT basis?  That is,
can a single interface be configured to appear as a passive interface in
some MT, not to appear at all in other MT and, maybe, be an active
interface in other MT.

3.  The Extended Inter-Area-Prefix-LSA, Extended AS-External-LSA,
Extended Link-LSA and Extended Intra-Area-Prefix-LSA include a prefix
block.  Is there any reason why this is not defined as a TLV?  In the
draft, it has no type field, only a length.  The meaning must be deduced
from its position in the LSA.

4.  There are 2 places in the draft where the phrase "the only top level
TLV defined by this document" is used, in sections 20.1 and 20.4.
Should this read "the only top level TLV defined by this document for
this LSA"?

Minor Editorial Comments
------------------------

1.  There are multiple places in the draft where the future tense is
used.  I think that the present tense is more normal in IETF drafts.

2.  There are multiple places where the text states that "all fields are
defined as in [OSPFv3]".  I think that it is more accurate to state that
"all fields not defined in this document are as defined in [OSPFv3]".

3.  There are multiple places in the code where lower case "must" is
used.  I think that upper case MUST should be used instead, in line with
RFC 2119.  For example, see second to last paragraph in section 20.1.

4.  Given the length of the draft, you may want to consider adding a
Table of Contents.

5.  Minor editorial nits.

Section 4., first sentence:

s/in Options filed/in the Options field/

Section 5., first sentence:

s/in LS type/in the LS type/

Section 8., first sentence:

s/We define a 8 bit/We define an 8 bit/

Section 9., header:

s/MT Control packet/MT Control Packets/

Section 11.,  first sentence:

s/metrics in E-router-LSA/metrics in the E-Router-LSA/

Section 12., first sentence:

s/When a MT-capable router participate in non-Default/When a MT-capable
router participates in non-Default/

Section 13., first sentence:

s/On multi-access links, the DR is responsible to generate prefix-LSA/On
multi-access links, the DR is responsible for generating prefix-LSA/

Section 15., first sentence:

s/it's MT-ID value is carried/its MT-ID value is carried/

Section 16., first sentence:

s/only routes belonging to the single/only routes belonging to a single/

Section 19., second paragraph:

s/RFC2740Compatibility can be set to disable/RFC2740Compatibility can be
set to disabled/

Section 20.1, last sentence in paragraph 1:

s/Each TLV could further contains sub-TLVs./Each TLV MAY contain
sub-TLVs./

Section 20.2, paragraph 5:

Suggest

	An Attached-Router TLV (AR-TLV) is defined. This TLV has similar
contents to the network-LSA payload.

	The E-network-LSA MUST contain an AR-TLV.

Instead of

	We define a Attached-Router TLV (AR-TLV). This TLV has similar
contents as the network-LSA payload.

	E-network-LSA must contain AR-TLV.

Section 20.6, second to last paragraph on page 19:

s/if the link participate in a MT/if the link participates in a MT/