[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. 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? 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). 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. Thanks, Chris. [as wg-member]
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
