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

[Imtiyaz Mohammad <[e-mail]>]

Thanks Les. That clears.

On Fri, Aug 14, 2015 at 9:08 PM, Les Ginsberg (ginsberg) <[e-mail]
> 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:[e-mail]] *On Behalf Of *Imtiyaz
> Mohammad
> *Sent:* Thursday, August 13, 2015 3:59 AM
> *To:* [e-mail]; [e-mail] 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 ( 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
>