Folks – John makes a very good point below in regards to the sub-TLV format for KEY-CHAIN-NAME Sub-TLV.
IS-IS never pads – because it is pointless and wastes space. But more importantly, the “length” field of any TLV/sub-TLV is used to find your way to the start of the next TLV/sub-TLV. The notion that the actual space of the sub-TLV is potentially longer than the length field simply never occurs in IS-IS – and I would not want to introduce an exception just for this case. Rather than do what John suggests below (have two lengths in the encoding), please define distinct formats for each protocol. This should be done for the KEY-ID sub-TLV as well. This is not only consistent with the behavior of each protocol, it is consistent with what has been done in RFCs 5088/5089. Using the same sub-TLV code point across both protocols is fine since we constrain it to sub-TLVs under the PCED advertisement – but please - protocol specific sub-TLV format definitions always. Thanx. Les +Next question, what does the Length field indicate, exactly? Is it the +length of the string? Presumably so, since there is no termination +character. Please say so, and say what the units are (e.g., "Length: +length of the Key Name field, in octets"). + +Finally, at the end of the description of the Key Name field, you say +"The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned." +Since we've already established that the Length field must indicate the +Key Name field length, what tells the parser how many bytes of padding +are present? Is it just supposed to know, based on whether the Key Name +field falls on a word boundary or not? Because, the Length field isn't +going to tell it. + +Perhaps all OSPF and IS-IS TLV parsers are robust to this kind of format; +if so let's discuss. But Occam's Razor suggests that the format documented +here isn't quite right, and that it should be something more like: + + Type: 7 + Length: Variable + Key Name: + String Length: one octet whose value is the number of octets + in the Key Name + String: zero or more characters of (whatever the supported + alphabet is). + Padding: 0-3 octets of padding, such that the sub-TLV is 4-octet + aligned. + +So there are two length fields: one is the usual TLV length field, that +tells you the size of the value portion. The other is the string length, +and it's needed because you're going to add 0-3 bytes of padding. If you +didn't use the padding, you could get away with a single length field, +but since you do have padding, you need both fields, it seems. + +That obviously isn't a finished description but it gives you the idea.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
