Henk,
A very sensible email.
John
On Thursday, October 31, 2024 at 06:28:32 AM PDT, Henk Smit
<[email protected]> wrote:
Please stop. > I suggest we can have a container TLV No.
There are two types of problems.
1) Short-term problems. Which have to be fixed asap. 2) Long-term problems.
Which need a proper solution. Container TLVs are not a good short-term
solution, and not a good long-term solution. The split TLV problem has
been solved for the short term. The multipart-TLV fix has been implemented by
multiple vendors. It has been deployed in multiple production networks.
It works. There is no need for a 2nd short-term solution. Your 2nd
solution also is not backwards compatible. So it has no benefits of the
multipart-TLV solution.
I see 0 benefit of having container TLVs over the multipart-TLV solution.
Neither do most other people here in the working-group. Can you not clearly see
that when you read the responses? If we want to think of a better
solution, we should fix this properly.
As Hannes already suggested: the proper fix is to bump the IS-IS protocol
version, and have 16-bit Type and 16-bit Value TLVs.
This is a huge change. And not backwards compatible. I am a fan of rule
#12 in RFC 1925. Keep your protocols simple. 16-bit Types and 16-bit Value
TLVs are a simple concept. They don't change anything to the algorithms or
behaviour of IS-IS. It's just "a small matter of programming" to implement
them. My countryman Edsger Dijkstra (you might have heard of him) has
said this:
".Elegance is not a dispensable luxury but a factor that decides between
success and failure."
Elegance means: simple and yet effective. Multipart TLVs are an ugly hack,
imho. But so are container TLVs.
We already have a (working and deployed) short-term solution.
If we're gonna have a 2nd solution, it should be elegant. Not yet another hack.
Just my own opinion. Not my employer's. But I think both my colleagues,
as well as most other people on this list, agree with me. Kind regards,
henk.
On 10/31/2024 6:28 AM CET [email protected] <[email protected]>
wrote: Hi, Aijun and Chiris Some personal understanding to
share. If any misunderstanding, please correct me. Thanks in advance.
I agree that the MP-TLV in draft-ietf-lsr-multi-tlv can work here.
However, I agree that we also need a more general way. In addition, I
suggest we can have a container TLV with a CSN (container sequence number).
Therefore, it create anther layer for the encapsulation of the big TLV.
Perhaps it has similar function to the Identification in the current
draft-wang-lsr-isis-big-tlv . I do not think they are very completed. Perhaps
more discussion is needed here. For example, we have a TLV type 16
and length 16, we can encapsulate it in several container TLVs with type 8 and
length 8. Figure1: A type 16 and length 16 TLV 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (T) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ | Piece 1 (less than
248 octets)| | ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Piece 2 (less
than 252 octets)| | ~
~ Bigger than
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 octets ~
: ~ |
~ . ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Piece n (less than 252 octets)| |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+
After encapsulation 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ |
container sequence number =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Type (T) =16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Length =16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Piece 1 (less than
248 octets)| | ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ |
container sequence number =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Piece 2 (less than
252 octets)| | ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ |
container sequence number =n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Piece n (less than
252 octets)| | ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Best Regards Zongpeng Du [email protected] &
[email protected]
From: Aijun Wang Date: 2024-10-28 16:22 To: 【外部账号】Christian Hopps
CC: Hannes Gredler; Aijun Wang; Yingzhen Qu; lsr-chairs;
draft-wang-lsr-isis-big-tlv; lsr Subject: [Lsr] Re: [Further Discussion]It's
time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot
Requests Hi, Chris: Let’s discuss your proposal and Les’s
responses more further. First, depending on RFC7356 to solve the
potential problem is not practicable—You must define all the new types for
possible big IS-IS TLV, and also their relevant sub-TLVs. It’s obviously not
the candidate solution. On the contrary, the updated Big-TLV
proposal(https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv/) needs
only to define one new generic TLV to solve all possible big-TLV problem, and
also their sub-TLVs. Second, regarding to Les’s responses at
https://mailarchive.ietf.org/arch/msg/lsr/iL-3bd3LC9ZfYftZUyky3bWyX4E/: “
This is why some RFCs left the choice in such cases to the implementor. I
mention this only to avoid an argument about trying to retrofit this model to
codepoints where this choice was not made. It isn’t worth the trouble and would
instantly render some implementations non-conformant without significant
benefit.” It’s possible that there are in private negotiation among
different vendors when there are interoperability issues from such implicit
“what constitutes a key”, such situations will be deteriorated when these
TLV/sub-TLVs are sliced according to the MP-TLV proposal. The MP-TLV
proposal will amplify such non-conformant issues. It’s time to find one
general solution to Big-TLV problem.
Aijun Wang China Telecom
Aijun Wang China Telecom
On Oct 26, 2024, at 20:09, 【外部账号】Christian Hopps <[email protected]> wrote:
Hannes Gredler <[email protected]> writes:
Why are we having this discussion again ?
My recollection is that we have a “good enough” solution that is
deployed and interoperable.
If you want the “generic solution” then the 16-bit TLVs described in
RFC7356 is the way to go forward and if there is concern about
incremental deployment then we should work on this aspect.
I also believe the 16 bit solution is the way forward if people wish to do any
more on this at this point.
Thanks,
Chris.
[as wg-member]
/hannes
On 23.10.2024, at 00:50, Aijun Wang <[email protected]>
wrote:
Hi,Chris:
Please elaborate clearly your technical reviews for the updates
of the newly proposed Big-TLV solution.
I can copy the updates again at here and state their effects
clearly.(https://mailarchive.ietf.org/arch/msg/lsr/
dxK4Gy1WDR7QCXK6p58xgA0MdUc/ )Please give your analysis before
you make any conclusions:
A new version of Big-TLV document has been
posted(https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv), to
try to give the community one general way to solve the Big TLV problem.
The main changes from the previous versions are the followings:
1) Add one "Identification" field within the container TLV(type TBD1), to
function as the key for any sliced TLV, and is TLV code point independent.
2) Add one "Flag" field, define currently the "F" bit to indicate whether
the piece of container is the first piece(F bit is set to 1), or not (F bit is
unset)
3) Put all the sliced pieces within the newly defined container TLV(type
TBD1).
4) Define some rules for the "Split and Glue" procedures(may be
re-optimizer later after the WG discussions)
The updated version erases the necessity of defining the "key" information
for every IS-IS (Possible Big) TLV code point, and also the necessity of
per-TLV capability announcement.
I would like to hear your detail analysis, especially as the WG chairs, for
the above statements.
Aijun Wang
China Telecom
On Oct 22, 2024, at 20:15, 【外部账号】Christian Hopps
<[email protected]> wrote:
Those changes don't appear to address what the WG already
decided against. The view of the WG was that a new Big TLV
for doing this was not going to work. Given the name of this
work is Big TLV, that doesn't seem to have changed. So why
should the WG be spending even more time on a solution they
already discussed, debated and discarded?
Thanks,
Chris.
[as wg chair]
On Oct 22, 2024, at 06:47, Aijun Wang
<[email protected]> wrote:
Hi, Chris:
No, we have made some significant updates.
Please refer to https://mailarchive.ietf.org/arch/msg/lsr
/dxK4Gy1WDR7QCXK6p58xgA0MdUc/ for more information.
Aijun Wang
China Telecom
On Oct 22, 2024, at 17:04, 【外部账号】Christian
Hopps <[email protected]> wrote:
Is this the same thing that Huaimo has already
presented to the WG, that the WG decided was not the
way it wanted to go?
Thanks,
Chris.
"Aijun Wang" <[email protected]> writes:
Hi, Yingzhen:
I would like to request 10-15minutes to make the
presentation for the
“IS-IS Extension for Big TLV”
The related information are the followings:
Draft Name: IS-IS Extension for Big TLV
Link: https://datatracker.ietf.org/doc/
draft-wang-lsr-isis-big-tlv
/
Presenter: Aijun Wang
Desired Slot Length: 10-15minutes.
Best Regards
Aijun Wang
China Telecom
发件人: [email protected]
[mailto:[email protected]] 代表
Yingzhen Qu
发送时间: 2024年10月12日 3:54
收件人: lsr <[email protected]>; lsr-chairs
<[email protected]>
主题: [Lsr] IETF 121 LSR Slot Requests
Hi,
The draft agenda for IETF 121 has been posted:
IETF 121 Meeting Agenda
The LSR session is scheduled on Thursday Session
I 09:30-11:30, Nov 7th, 2024.
Please send slot requests to [email protected]
before the end of the day
Wednesday Oct 23. Please include draft name and
link, presenter, desired
slot length including Q&A.
Thanks,
Yingzhen
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
<signature.asc>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
