[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]

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to