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 protected]] On Behalf Of Imtiyaz Mohammad Sent: Thursday, August 13, 2015 3:59 AM To: [email protected]; [email protected] 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: =========== 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<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: ----------------------------------------- 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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
