[As wg-member] --- inline...
"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
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
The need is not a surprise to me, no.
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.
That discussion had to do with whether to include a bit that is for management
purposes only. What I am seeing here is a need for an operationally relevant
bit (i.e., determines how the protocol functions).
AFAICT we now have implementations out there that are sending multiple TLVs
which are not documented to be sent that way, that historically were not
expected to be received that way, and then we have other implementations that
do not expect this new, convenient but rather loose interpretation of the
standards. Consider we have documents that explicitly state that a TLV can be
sent multiple times, it would be completely normal for someone to then assume
that when that isn't stated explicitly that multiple versions of those TLV will
not be sent.
Thus the need for this document -- in some form.
Having all routers work from the same link-state database is basic requirement
to the correct functioning of the decision process.
Are we just lucky that things haven't really broken yet? How can an operator
even know what they've got deployed? Before this document there's nothing to
even refer to to document the possible different behaviors.
If people want to argue that no operationally significant bit is needed then
how can an operator be expected to get this right? What is the exact process
they should follow to have interoperating routers?
Thanks,
Chris.
[as wg-member]
Les
Thanks,
Chris.
[as wg-member]
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
