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

From: Alan Davey <[email-masked]>
Date: Thu, 19 May 2005 10:47:09 +0100

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:   +44 20 8366 1177
Fax:   +44 20 8363 1039
Email: [email-masked]
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/

---

From: Sina Mirtorabi <[email-masked]>
Date: Fri, 20 May 2005 11:41:05 -0700

Alan,

-> 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.

Ok 

-> 
-> 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.

Right, on the other hand restricting TLV type to a given LSA (i.e. define
same type in different LSA) give more Type space for use and also removes
any possibility of expecting the "wrong" TLV in the wrong LSA type. That
said we are not against of changing that to global scope

-> 
-> 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.

sub-TLV may appear in value filed of TLV, without the S bit you would not be
able to tell if the next field correspond to sub-TLV or is yet another value
field in TLV

-> 
-> -  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.

The S bit is present whenever the presence of sub-TLV is optional, for
E-router-LSA, Link-description (LD) TLV is a mandatory sub-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?

This allows nesting of sub-TLVs to deeper levels, e.g. define extension
under MT

-> 
-> 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

Total sub-tlv length is useful when the value field in the TLV is more than
one (and multiple sub-TLV are present). This is the only way to get to the
next Value within the same TLV.

-> -  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.

In order to interoperate, by default rfc2740compatibility is set to enable
and existing LSA is used for default topology, once all routers are MT
capable new LSA could be used for default topology

-> 
-> -  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.

We could add that the default topology is the topology that is built by
either using existing LSA or using extended LSA with MT-ID#0

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

Ok

-> 
-> 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.

You need that in order to define extension under each MT

-> 
-> 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.  

Why not? The presence of Tag, FA, Sub-TLV explicitly marked with the
corresponding bits (i.e. T, F, S)

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

Again you need sub-TLV to define extension under each MT

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

If it is defined to interact with MT extension, yes

-> 
-> 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.

Yes, when the interface is passive in a given topology, there is no
adjacency advertised in e-router-LSA but simply the prefix is advertised in
e-intra-area-prefix-LSA

-> 
-> 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.

It is more compact and there is really no need to carry a type, all we want
is to define TLV under each Prefix address and being able to define the next
block. That said we are not against changing the prefix block to TLV (and
its TLV would become sub-TLV...)

-> 
-> 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"?

Ok

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

Will change that

Thanks
Sina