Thanks Les. That clears. On Fri, Aug 14, 2015 at 9:08 PM, Les Ginsberg (ginsberg) <[email protected] > 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 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 ( 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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
