Eric – I made additional changes and posted V14 which I hope addresses all your comments.
I am top posting here those items on which I chose not to make the suggested changes. Hopefully you will agree – but if not we will continue to discuss. Thanx again for your review and your prompt responses. > Strongly suggest to indicate that the MP-TLV capability is negotiated (as I > had > big ??? in mind until section 7). [LES:] MP-TLV is NOT negotiated - and there is no practical way to do that. Safe use of MP-TLV for a particular codepoint requires all nodes in the network to support it - as discussed in Section 8. But having implementations dynamically enable/disable MP-TLV based on some advertised state is extremely problematic. It can lead to highly undesirable oscillation in the event a node which does/does not support MP-TLV is added/removed from the network. This is a non-goal. Which is why Section 7 states: "This advertisement is for informational purposes only. Implementations MUST NOT alter what is sent or how what is received is processed based on these advertisements." EV> hmm you probably know better than me about negotiation vs. information, but saying in section 1 that this capability can be advertised will probably help the reader [LES2:] I really do not want to do this. The new sub-TLV is – as we have been discussing – optional/informational. If it had never been defined, the draft would still be complete. That said, the consensus of the WG, after much discussion, was to include this sub-TLV even with its limitations. I really do not want to reopen that discussion – nor do I want to place additional emphasis on something that is non-essential. You, somewhat understandably, would like more clarity – but I don’t think what you suggest provides that. What operators would really like is to know the precise support an implementation has. This is management information – does not belong in the protocol itself. We have defined how to address that by introducing YANG definitions of Protocol Implementation Conformance Statements (PICS). See https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-l2member-attr-yang/ https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-srmpls-yang/ https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-srmpls-yang/ https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-yang/ > > ### Section 4 > > Bear with my lack of IS-IS expertise, but can a IIH message be fragmented in > several layer-2 packets ? If so, how can a node differentiate between recent > and old TLV in "MP-TLV" bundle (i.e., are these TLV parts of a unique bundle > or > separates ones) ? > [LES:] No - IIHs do not support fragmentation. Occurrences of MP-TLV in an IIH are within a single PDU. EV> Excellent, I was fearing a fragmented IIH and some complications for “reassembly” of all TLVs ;-) EV> Now, I *strongly* suggest to indicate somewhere in the text that “Occurrences of MP-TLV in an IIH are within a single PDU” EV> Does the same reasoning applies to LSP PDU ? [LES2:] Multiple LSPs can be generated by a node and TLVs can appear in any LSP, so the same limitation does not apply to LSPs. The current text in Section 4 is: “If a router advertises multiple TLV tuples with the same TLV type and the same key (when applicable) in an IS-IS Hello (IIH) packet or in the set of LSPs for a given level, they are considered a Multi-Part TLV (MP-TLV). Note the phrases “an IS-IS Hello” and “in the set of LSPs”. I believe this already states what you are after. > ### Section 9.2 > > Should there be guidance for the designated experts ? > [LES:] Guidance is provided in RFC 7370 - which is explicitly stated at the top of https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml EV> I meant guidance for the new column/field [LES2:] Yes – I understood that. 😊 I don’t think additional guidance is required. The meaning of the new bit is fully described in this draft. To determine whether the setting of the bit in a document describing a new codepoint is correct requires that one understand the encoding of the new codepoint so that it can be determined if it is possible for MP-TLV to be required. By definition, anyone who is expert in the IS-IS protocol is capable of making this fundamental evaluation. Les
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
