[Isis-wg] Indication of presence or absence of subTLVs in Router Capability TLV and SR binding TLV

[Imtiyaz Mohammad <[e-mail]>]

Hello experts !

I am perplexed looking at the different ways present or nor present in a
bunch of ISIS TLVs I have came across recently. Wish to get my questions
clarified here.

I have seen that implementations put multiple VALUES of the same TYPE
within one single block. In other words, if we were to advertise Extended
IPv4 reachability (type 135) for prefix 99.1.1.1/32 ( with prefix SID
subTLV), 5.5.5.0/24 ( no subTLV ), 3.3.3.0/24 (no subTLV ), we would do so
as follows ( fabricated tcpdump o/p ):

TLV FORMAT:
===========
   4 octets of metric information
   1 octet of control information, consisting of
      1 bit of up/down information
      1 bit indicating the presence of sub-TLVs
      6 bits of prefix length
   0-4 octets of IPv4 prefix
   0-250 optional octets of sub-TLVs, if present consisting of
      1 octet of length of sub-TLVs
      0-249 octets of sub-TLVs, where each sub-TLV consists of a
      sequence of
         1 octet of sub-type
         1 octet of length of the Value field of the sub-TLV
         0-247 octets of value

EXAMPLE:
========
            Extended IPv4 Reachability TLV #135, length: 34
                  IPv4 prefix:        99.1.1.1/32, Distribution: up,
Metric: 10, sub-TLVs present (8)
                       Segment Routing Prefix Segment subTLV #3, length: 6,
Flags: N Algorithm: SPF, Index: 1
                 IPv4 prefix:        5.5.5.0/24, Distribution: up, Metric:
10
 IPv4 prefix:        3.3.3.0/24, Distribution: up, Metric: 10

As could be observed, We have encompassed the three prefixes and other
associated information within one single block that could be represented as:

-----------------------------------------
Type
Length
Value1(metric, control, prefix, subTLV)
Value2(metric, control, prefix)
Value3(metric, control, prefix)
-----------------------------------------

Instead of separate instances of the same TLV, as shown below:

-----------------------------------------
Type
Length
Value1(metric, control, prefix, subTLV)
-----------------------------------------
Type
Length
Value2(metric, control, prefix)
-----------------------------------------
Type
Length
Value3(metric, control, prefix)
-----------------------------------------

When parsing the LSP buffer, when we are at value1, we know whether or not
value1 contains subTLVs based on subTLV present bit in the control octet of
extended IP reachability TLV. This way, we know that we have a Value1,
subTLV, Value2 in the buffer instead of Value1\
, Value2.

Let's consider Extended IS Reachability ( type 22 ) now.

FORMAT:
========
      7 octets of system ID and pseudonode number
      3 octets of default metric
      1 octet of length of sub-TLVs
      0-244 octets of sub-TLVs, where each sub-TLV consists of a
      sequence of
         1 octet of sub-type
         1 octet of length of the Value field of the sub-TLV
         0-242 octets of value

EXAMPLE:
========
            Extended IS Reachability TLV #22, length: 22
                  IS Neighbor: 1111.1111.0003.00, Metric: 10, no sub-TLVs
present
                        IS Neighbor: 1111.1111.0002.0d, Metric: 10, no
sub-TLVs present

Again, we have Type, Length, Value1( data associated to 1111.1111.0003.00 )
and Value2 ( data related to 1111.1111.0002.0d )

-----------------------------------------
Type
Length
Value1
Value2
-----------------------------------------

To summarize, the presence of subTLV present bit in Extended IP
Reachability TLV subTLV length field in Extended IS reachability TLV helps
us parse a representation where multiple VALUE blocks can be encompassed
within one Type/Length block.

For implementing Segment Routing using IS-IS as IGP one would need to
support Router Capability TLV (Type #242) and SR Label Binding TLV (Type
#149)

We noticed that these two TLVs neither have a subTLV present bit in any
flag in the VALUE part of the TLV nor do they have a subTLV field. Without
knowing whether the VALUE block has a sub-TLV or not, we would not be able
to support the following way of encoding.

-----------------------------------------
Type
Length
Value1
Value2
-----------------------------------------

When we are at Value1, we would not know if the information in the next
byte is meant to represent another instance of VALUE (Value12) or subTLV of
Value1. The only model that makes sense then is:

-----------------------------------------
Type
Length
Value1
-----------------------------------------
Type
Length
Value2
-----------------------------------------

Summarizing my questions:
=========================
1) Why do we have such an non-uniform way of denoting or not denoting
whether sub-TLVs are present or not ? A bit and sub-TLV len field in type
135, just a subTLV len field in type 22 and no indicators in type 242 and
type 149.

2) Is it agreed and understood by all implementations that type 242 and
type 149 would be present in an LSP as multiple instances of T,L,V tuples
instead of T,L,V,V,V blocks ?

Thanks,

Imtiyaz