Chris - Please see inline - I'll try to conform to your request about ">>>" quoting - but given that this style does not identify who made the comment, I have found in the past that this style becomes very hard to follow after a couple of replies. Though perhaps that could be said of any style. 😊
> -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Tuesday, March 28, 2023 7:27 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Huaimo Chen <huaimo.c...@futurewei.com>; draft-chen-lsr-isis-big- > tlv.auth...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00 > > > Hi, > > So I agree that using this new container TLV along with old TLVs doesn't help. > >>[LES:] Good - we agree. > However, it is worth nothing that if *only* the container TLV was used (i.e., > once a TLV became too large it would be removed and placed inside > container TLVs) then it would actually represent a safer way to deploy this > "multiple tlv" functionality. > > If the container only was used, then only routers that understood would be > able to use *any* of the TLV data. This would actually solve the problem of > "newly inserted legacy router brings everything back down" that using a > required capability bit being set on all routers has. > >>[LES:] I don't agree - and here is why. Let's use the example of Neighbor >>TLVs. >>With what you propose, when a router starts using the container TLV, those >>routers who don’t support/understand it would simply not be aware of the >>advertisement at all. >>This would result in inconsistent routing calculations on different routers >>leading to loops/blackholes. >>Hardly a benign impact. >> >>There is no free lunch here. No matter what encoding scheme you come up with, >>unless all routers in the network understand it, things are going to break. > This later issue with the capability bit is why no-one wanted to use a it, and > why we currently have this very sub-optimal "solution" of "just do it and > hope it works". >>[LES:] Folks (like me) who implemented MP for TLVs like Neighbor/Prefix were >>following established practice for the protocol i.e., there are multiple >>cases where this behavior is explicitly specified (please see MP draft for a >>list) >>So it made sense to use the same mechanism for other TLVs. >>We are not naïve - we understood very well that if not all routers in the >>network supported at least reception of MP TLVs that there would be >>deployment issues. >>That is why I am working with enthusiasm on the MP draft. Les > > Thanks, > Chris. > [as wg-member] > > > P.S. the quoting style used in this thread is fabulously hard to comprehend in > a text based email client.. What's wrong with good old ">>>" quoting style > anyway? > > > "Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> writes: > > > Huaimo – > > > > > > > > Please see inline. > > > > > > > > From: Huaimo Chen <huaimo.c...@futurewei.com> > > Sent: Sunday, March 26, 2023 3:41 AM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org; > > draft-chen-lsr-isis-big-tlv.auth...@ietf.org > > Subject: Re: Comments on draft-chen-lsr-isis-big-tlv-00 > > > > > > > > Hi Les, > > > > > > > > Thanks much for your comments. > > > > My responses are inline below with HC. > > > > > > > > Best Regards, > > > > Huaimo > > > > > > > > From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > > Sent: Thursday, March 23, 2023 3:35 AM > > To: lsr@ietf.org <lsr@ietf.org>; > > draft-chen-lsr-isis-big-tlv.auth...@ietf.org < > > draft-chen-lsr-isis-big-tlv.auth...@ietf.org> > > 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? > > > > > > > > [LES:] Please read draft-pkaneria-lsr-multi-tlv-02 carefully. > > > > Section 1 documents that there are existing RFCs which explicitly > > state that multiple TLVs for the same object are allowed to be sent. > > > > What the draft goes on to discuss is the use of the same mechanism > > (sending multiple TLVs for the same object) in cases where existing > > RFCs have not explicitly stated this behavior. > > > > > > > > It is also a fact that there are multiple implementations from > > multiple vendors already shipping that utilize this mechanism for > > TLVs such as Neighbor and Prefix reachability. > > > > > > > > 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. > > > > [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? > > > > > > > > [LES:] There are no protocol extensions defined in > > draft-pkaneria-lsr-multi-tlv-02 (please see the statement in the IANA > > section). The draft has been written to clarify existing behavior and > > to discuss best deployment practices in cases where not all > > implementations support reception of multiple TLVs for a given > > object. > > > > > > > > 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. > > > > > > > > [LES:] This would the worst possible outcome. > > > > It would define two mechanisms for sending more than 255 bytes of > > information about an object. > > > > This would require implementations to support two different > > mechanisms for advertising the same information – also requiring the > > ability to control which mechanism should be used in a given > > deployment and even raising the possibility that both forms would > > need to be sent in parallel. This adds unnecessary complexity to > > implementations. > > > > > > > > For operators deploying features+scale which require such support, > > they would now have to identify not only whether all implementations > > in their deployment support sending/receiving more than 255 bytes/ > > object, but also which form of advertisement is supported – further > > complicating deployment considerations. > > > > > > > > And since there are explicit statements requiring the current form of > > advertisement to be used for some TLVs, behavior would potentially > > differ on a per TLV basis. > > > > > > > > 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. > > > > [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. > > > > > > > > [LES:] Consider the following simple example. > > > > Node A needs to send 10 sub-TLVs about a particular object – > > requiring more than 255 bytes to be sent. > > > > Some nodes in the network do not support reception of more than 255 > > bytes/object. Consider two such nodes. > > > > Node B, based on the local configuration, needs to be able to receive > > sub-TLVs 1,3,5,7,9 from A. > > > > Node C, based on local configuration, needs to be able to receive > > sub-TLVs 2,4,6,8,10 from A. > > > > > > > > There is no way that A can advertise all 10 sub-TLVs in a way which > > allows both B and C to correctly process the sub-TLVs they require. > > > > > > > > Network functionality is compromised. > > > > > > > > It is true that even with the existing solution unless all nodes are > > capable of processing more than 255 bytes of information/object > > network functionality will be compromised. That is exactly what > > motivated the writing of draft-pkaneria-lsr-multi-tlv. > > > > But your proposal does nothing to make that requirement easier to > > address. It in fact makes implementation/deployment even more > > difficult – as I have described above. > > > > > > > > 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. > > > > > > > > [LES:] You are proposing a second solution for a problem that has > > already been solved. In doing so you are introducing new problems and > > not solving any existing issues. Saying this “does no harm” is > > clearly false. > > > > > > > > Les > > > > > > > > > > > > The draft should be abandoned. > > > > > > > > Les > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
