Folks -
This draft proposes a new way to handle advertisement of more than 255 bytes of information about a given object. It defines a new "container TLV" to carry additional information about an object beyond the (up to) 255 bytes of information advertised in an existing TLV. The draft is defining a solution to a problem which has already been addressed without requiring any protocol extensions. The existing solution - discussed in https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ has already been successfully implemented and deployed by multiple vendors. The definition of a second solution to the problem is not needed - and in fact further complicates both implementation and deployment. Should the existing solution be used? Should the new solution be used? What is the state of support by all nodes in the network for each solution? The motivation for the new solution seems to be the notion that it supports partial deployment. Text in https://www.ietf.org/archive/id/draft-chen-lsr-isis-big-tlv-00.html#name-incremental-deployment states: "For a network using IS-IS, users can deploy the extension for big TLV in a part of the network step by step. The network has some nodes supporting the extension (or say new nodes for short) and the other nodes not supporting the extension (or say old nodes for short) before the extension is deployed in the entire network." This suggests the authors believe that a network can function with some nodes using all of the advertisements and some nodes using only the legacy advertisements, but this is obviously false. Fundamental to operation of a link state protocol is that all nodes in the network operate on identical LSPDBs. The suggestion that features will work correctly when some nodes use attributes advertised in legacy TLVs and the new container TLV while some nodes use only the attributes advertised in legacy TLVs is simply incorrect. It is also important to also state that the advertisement of more than 255 bytes of information is driven by configuration - not a protocol implementation choice. Suppressing advertisement of some of the configured information also does not result in a working network. In short, there is no positive value from the proposed extension - and it does harm by further complicating implementations and deployments. The draft should be abandoned. Les
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
