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

[Sina Mirtorabi <[e-mail]>]

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