Hi Huaimo, The first draft builds on existing mechanisms and procedures. The second draft is redundant and adds no value whatsoever.
Regards, Tony > On Mar 26, 2023, at 3:40 AM, Huaimo Chen <[email protected]> wrote: > > Hi Les, > > Thanks much for your comments. > My responses are inline below with HC. > > Best Regards, > Huaimo > From: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>> > Sent: Thursday, March 23, 2023 3:35 AM > To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>> > Subject: Comments on draft-chen-lsr-isis-big-tlv-00 > > 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. > [HC]: It seems that a protocol includes a set of procedures. Would you mind > telling me which existing protocols can be used to resolve the problem > without requiring any protocol extensions? > > The existing solution - discussed in > https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-pkaneria-lsr-multi-tlv%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C6e9af0fb3bcd4bef57a408db2b7125a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638151537195561122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=23RCLltpVh%2BmKSaVzz6v%2FprNKtUU%2Bqx0FEik6x7qvHs%3D&reserved=0> > has already been successfully implemented and deployed by multiple vendors. > [HC]: You are a co-author of this draft, called a first draft for resolving > the problem on big TLVs. This first draft contains some protocol extensions. > If there is a solution for the problem without requiring any protocol > extensions, then why do you as a co-author work on the first draft with > protocol extensions? > > 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? > [HC]: It seems better to merge the two drafts (i.e., the first draft and the > second draft defining container TLV) into one. > > 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 > > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-lsr-isis-big-tlv-00.html%23name-incremental-deployment&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C6e9af0fb3bcd4bef57a408db2b7125a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638151537195561122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AwI4YHL1uPDwbqPoCtjvobS424RT3OGNWdUxM9XclUY%3D&reserved=0> > 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. > [HC]: Every node in the network has the same LSPDB. The new nodes understand > the new container TLVs and may use them. The old nodes do not understand them > and do not use them. > > 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. > [HC]: The second draft defines a general mechanism for resolving the problem. > It is backward compatible and simple. It does not do any harm. > > The draft should be abandoned. > > Les > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
