Aijun,
You didn't mention the most significant part of Mike's note, viz,
"I understand and agree
with the WG consensus that the key for each relevant TLV is sufficiently clear
to implementers in practice. This document acknowledges and formalizes an
existing workaround actively being used, and existing successful interoperation
is the best evidence that this is clear to implementers."
Do you know the term "beating a dead horse"?
John
On Wednesday, April 16, 2025 at 07:31:26 PM PDT, Aijun Wang
<[email protected]> wrote:
Hi, Mike:
I agree with you that " it would be nice to have a crisper definition of the
"key" for each TLV,"
but not the " the WG consensus that the key for each relevant TLV is
sufficiently clear to implementers in practice."
Let me state the logic/reasoning more clearly(wish it will also help other
experts to understand. If there is any mistake for the following statements,
ANYONE can standout make it more clear, or correct me):
1) There is no 'key' definition on 'each relevant TLV(include also sub-TLV,
sub-sub-TLV) in current related IS-IS RFCs. If there is any, please show the
community the pointer.
2) The latest version(version 16) states the above point clearly: " Also, the
term "key" is a generic term which is not used in the relevant
specifications."----I MUST point out, other equivalent descriptions that have
the same function don't exist also.
3) Only this under-reviewed MP-TLV document provides the ‘key’ definition for
two TLVs： TLV 22 and TLV 135.
4) Even for these newly defined 'key' information for TLV 22 and TLV 135, there
is ambiguous( I have given the example at
https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv-01#section-3.1)
And, when I read carefully again the newest (version 16) MP-TLV document and
RFC 5305(which defines the TLV 22 and TLV 135 firstly) again, I found another
ambiguous, even for TLV 135:
1) In MP-TLV document, it states(newly defines) that " The key consists of the
6 bits of prefix length plus 0-4 octets of IPv4 prefix.",
2) But in RFC 5305, it states: " The prefix is encoded in the minimal number of
octets for the given number of significant bits. The remaining bits of prefix
are transmitted as zero and ignored upon receipt."
3) Then comes the ambiguous: if the "significant bits" is 27, the prefix must
be encoded in 4 Octets.
4) What the remaining bit should be encoded?-----The sender can encode it in
any way, even for the pieces of the same MP-TLV instance, does not violate the
guideline of MP-TLV and RFC 5305.
5) This will not arise interoperability issues for the non-MP-TLV scenario. But
for the MP-TLV scenario, the receiver can't ignore the remaining bits upon
receipt if such remaining bit is also the parts of the 'key' for the MP-TLV
pieces.
Here is the summary for the overall discussions until now:
For every raised issue, I give the very detail example, analysis and reasoning
for the unsolved challenges, but there is no any experts stand out to answer
them in the same detail, analysis and reasoning.
This shouldn't be the style of IETF community, which always focus on the
discussions on technical arguments, although there are other non-technical
issues that want to dominate/change the IETF traditional traits.
I don‘t want to repeat in detail other unsolved challenges again, just list
them here for reminder(nest encapsulation efficiency, unlimited boundary
attack, misguided MP-TLV capabilities advertisement)
If the IESG pass this document even notice these unsolved challenges, I will
try to raise it to IAB for the discussions of these technical arguments,
according to the procedures described in
https://datatracker.ietf.org/doc/html/rfc1603#section-3.4
I will not argue the overall process of this document, only the above technical
arguments.
If ANY expert can STAND OUT to give the "detail example, analysis and
reasoning" about these points, I would like to hear.
I would like also the IESG/IAB hold one public hearing meeting(it will be more
efficient) in future for these arguments to this MP-TLV proposal.
Best Regards
Aijun Wang
China Telecom
-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表 Mike
Bishop via Datatracker
发送时间: 2025年4月17日 0:10
收件人: The IESG <[email protected]>
抄送: [email protected]; [email protected]; [email protected];
[email protected]
主题: [Lsr] Mike Bishop's No Objection on draft-ietf-lsr-multi-tlv-16: (with
COMMENT)
Mike Bishop has entered the following ballot position for
draft-ietf-lsr-multi-tlv-16: No Objection
When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I had previously reviewed this document, as well as another objecting to it, in
the course of understanding the appeal that was raised. While it would be nice
to have a crisper definition of the "key" for each TLV, I understand and agree
with the WG consensus that the key for each relevant TLV is sufficiently clear
to implementers in practice. This document acknowledges and formalizes an
existing workaround actively being used, and existing successful interoperation
is the best evidence that this is clear to implementers.
_______________________________________________
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]
