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

From: Imtiyaz Mohammad <[email-masked]>
Date: Thu, 13 Aug 2015 16:28:46 +0530

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

---

From: Imtiyaz Mohammad <[email-masked]>
Date: Fri, 14 Aug 2015 22:02:50 +0530

Thanks Les. That clears.

On Fri, Aug 14, 2015 at 9:08 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Imtiyaz –
>
>
>
> Let me try to answer your questions – though it involves a bit of
> “archaeology”.
>
>
>
> RFC 5305 introduced TLVs 22 and 135. They were modeled after the original
> “narrow metric” versions TLV 2 (ISO10589) and TLV 128 (RFC1195) – both of
> which support multiple neighbors/prefixes in the same TLV.
>
>
>
> In the case of TLV 22 there is no flags field, so there is no opportunity
> to introduce a flag indicating sub-TLVs are present. Introducing a flags
> field would have taken up the same amount of space as the current field
> which indicates total sub-TLV length. Doing so would have only made the
> encoding less efficient in the case where sub-TLVs are present (one extra
> octet would have been required).
>
>
>
> In the case of TLV 135 there is a flags field. This allows support for a
> flag indicating sub-TLVs are present. In the case where the flag is clear
> (no sub-TLVs present) this saves one octet by eliminating the need to have
> a sub-TLV length advertised.
>
>
>
> In the case of TLV 242 (Router Capability), the format consists of:
>
>
>
> Type
>
> Length
>
> Fixed Header
>
> Sub-TLVs
>
>
>
> The “objects” which are advertised in Router Capabilities are always
> advertised in sub-TLVs unique to the particular object being described.
> There is no analog to a “neighbor” or “prefix” which needs to be repeated.
>
> Consult
> http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242
> for the sub-TLV codepoints supported.
>
>
>
> In regards to the Binding TLV (149), it is conceivable that the authors
> could have defined a format that supported multiple FEC advertisements and
> their associated sub-TLVs in a single TLV – but they chose not to do so –
> presumably to make the encoding a bit simpler.
>
>
>
> HTH
>
>
>
>    Les
>
>
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Imtiyaz
> Mohammad
> *Sent:* Thursday, August 13, 2015 3:59 AM
> *To:* [email-masked]; [email-masked] list
> *Subject:* [spring] Indication of presence or absence of subTLVs in
> Router Capability TLV and SR binding TLV
>
>
>
> Hello experts !
>
>
>
> 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:
>
> ===========
>
>                        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
>
> Again, we have Type, Length, Value1( data associated to 1111.1111.0003.00
> ) and Value2 ( data related to 1111.1111.0002.0d )
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Aug 2015 15:38:10 +0000

Imtiyaz –

Let me try to answer your questions – though it involves a bit of “archaeology”.

RFC 5305 introduced TLVs 22 and 135. They were modeled after the original “narrow metric” versions TLV 2 (ISO10589) and TLV 128 (RFC1195) – both of which support multiple neighbors/prefixes in the same TLV.

In the case of TLV 22 there is no flags field, so there is no opportunity to introduce a flag indicating sub-TLVs are present. Introducing a flags field would have taken up the same amount of space as the current field which indicates total sub-TLV length. Doing so would have only made the encoding less efficient in the case where sub-TLVs are present (one extra octet would have been required).

In the case of TLV 135 there is a flags field. This allows support for a flag indicating sub-TLVs are present. In the case where the flag is clear (no sub-TLVs present) this saves one octet by eliminating the need to have a sub-TLV length advertised.

Type
Length
Fixed Header
Sub-TLVs

The “objects” which are advertised in Router Capabilities are always advertised in sub-TLVs unique to the particular object being described. There is no analog to a “neighbor” or “prefix” which needs to be repeated.
Consult http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242 for the sub-TLV codepoints supported.

In regards to the Binding TLV (149), it is conceivable that the authors could have defined a format that supported multiple FEC advertisements and their associated sub-TLVs in a single TLV – but they chose not to do so – presumably to make the encoding a bit simpler.

HTH

   Les

From: spring [mailto:[email-masked]] On Behalf Of Imtiyaz Mohammad
Sent: Thursday, August 13, 2015 3:59 AM
To: [email-masked]; [email-masked] list
Subject: [spring] Indication of presence or absence of subTLVs in Router Capability TLV and SR binding TLV

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<http://99.1.1.1/32> ( with prefix SID subTLV), 5.5.5.0/24<http://5.5.5.0/24> ( no subTLV ), 3.3.3.0/24<http://3.3.3.0/24> (no subTLV ), we would do so as follows ( fabricated tcpdump o/p ):

TLV FORMAT:
===========

EXAMPLE:
========
            Extended IPv4 Reachability TLV #135, length: 34
                  IPv4 prefix:        99.1.1.1/32<http://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<http://5.5.5.0/24>, Distribution: up, Metric: 10
          IPv4 prefix:        3.3.3.0/24<http://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:

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.

FORMAT:
========

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 )

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.

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:

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