Chris -
> -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Monday, October 3, 2022 8:37 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Robert Raszuk <rob...@raszuk.net>; Tony Li <tony...@tony.li>; Henk Smit > <henk.i...@xs4all.nl>; lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > [As wg-member] > > I think the draft should include a table of all top level TLVS as rows and for > columns we have > > - "Implicit Single TLV Only" (e.g., no key info) > - "Implicit Multi-TLV Only" > - "Explicit Single TLV Only" > - "Explicit Multi-TLV-Allowed" > > This draft then would *explicitly* cover the existing "implicit" cases and we > have the table to point at to be precise about what we are talking about. > [LES:] I am not overly enthused about this - but I can see its usefulness, so I don’t oppose it. Probably best realized as an additional column in the existing IS-IS TLV Codepoints registry. But also realize that in some cases this extends to sub-TLVs (as one example "16 Application-Specific Link Attributes"). > Now about the capability... There's an argument about including a router > capability and it seems to be that people have agreed that it should *not* > have any operation impact on the protocol. > > I think this is hasty. I would like to look at the above table to see what > TLVs > we are *exactly* talking about here (the implicit multi-tlv ones). People have > said that implementations support multi-tlv use of these implicit cases (e.g., > the draft talks about extended reachability). > > Really? [LES:] Yes - really. 😊 > > I could easily believe its not common. I think we should get specific about > vendors and versions (and maybe specific TLVS?) if we are saying this has > been deployed and is in use. I've written a few IS-IS implementations and I > don't think *any* of them supported multiple tlvs of, for example, extended > reachability (seeing 2 of the same keyed info would be seen as one replacing > the other, or a bug if in the same LSP segment). [LES:] All of us who have "been around for a while" have worked on implementations that did not support MP-TLVs. Prior to new features (SR, TE Metric Extensions (RFC 8570), flex-algo, more extensive deployments of IPv6, etc.) there wasn't a need - at least for Neighbor/Prefix advertisements. But deployment requirements have evolved. We absolutely have cases today where a single TLV is insufficient space-wise for both neighbor and prefix advertisements and there are multiple implementations which already support this. If the WG wants to pursue an Implementation Report on this, I have no objection. BTW, the need for this should not surprise you. Discussion of this problem dates back at least to 2004: https://datatracker.ietf.org/doc/html/draft-shen-isis-extended-tlv-00 > > Once we have this info I think a stronger case might be made for actually > having the router capability be used *operationally* (i.e., if you don't see > the > capability advertised then that router in fact doesn't send multi-tlv tlvs and > they should be seen as replacements of each other), and the argument > about it's inclusion goes away as it's then required. > [LES:] I don't agree with this argument - but I think the discussion triggered by posts from Gunter and Henk has already covered this well from both points of view, so I won’t repeat here. Les > Thanks, > Chris. > [as wg-member]
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
