Les,
A very cogent and graceful explanation.
John
On Tuesday, October 22, 2024 at 10:23:50 PM PDT, Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org> wrote:
Soooo....for the benefit of the WG...
Aijun has sent many messages making the same claims. In the past I (and others)
have made attempts to explain to Aijun why he is mistaken.
For one example see
https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/
None of these responses have convinced Aijun that he is mistaken - so I do not
expect that this response will alter his opinion. In fact, I fully expect that
in response to this email Aijun will send yet another email making the same
mistaken claims. 😊
But I am not sending this in the hopes of altering Aijun's understanding.
I am sending this only to reassure other members of the WG who might not be as
familiar with the solution defined
inhttps://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ that what Aijun is
claiming is incorrect.
No encoding changes to any codepoint are required for the multi-tlv solution.
This is a hallmark of the solution as it ensures that implementations can use
existing code for encoding the TLVs they send and use existing code for parsing
the TLVs they receive.
The only implementation changes which are required have to do with treating two
TLVs for the same object as additive rather than as replacements for each
other. This is described in more detail
inhttps://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5
What seems to have confused Aijun is the use of the generic term "key" to
describe that portion of a given codepoint which uniquely identifies the object
associated with a given TLV. This isn't the introduction of new information -
it is simply a generic term for what is already being advertised in TLVs and in
fact already being processed on receive even in the absence of MP. What
constitutes a key is codepoint specific - but it is not new information that is
required when MP is in use. For example:
For IS-Neighbor TLVs the "key" is system-id and link identifiers (as described
inhttps://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.1 )
For Prefix Reachability TLVs the "key" is the prefix/length (as described
inhttps://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.2 )
For the BFD Enabled TLV the key is (MTID,NLPID).
Etc.
The fact that we did not describe in the draft the "key" for all codepoints for
which MP-TLV is applicable does not mean that additional information is
required to be sent in those codepoints when MP-TLV is in use.
This is a fundamental misunderstanding.
As I mentioned in a previous post, we have running code from multiple vendors
which prove that what I say above is correct.
Claims to the contrary indicate only that the person making those claims does
not understand the draft.
Thanx for listening.
Les
> -----Original Message-----
> From: Aijun Wang <wangai...@tsinghua.org.cn>
> Sent: Tuesday, October 22, 2024 8:53 PM
> To: 'Christian Hopps' <cho...@chopps.org>
> Cc: 'Yingzhen Qu' <yingzhen.i...@gmail.com>; 'lsr-chairs'
> <lsr-cha...@ietf.org>;
> draft-wang-lsr-isis-big-...@ietf.org; 'lsr' <lsr@ietf.org>
> Subject: [Lsr] 答复: Re: It's time to find one general solution to Big-TLV
> problem Re: IETF 121 LSR Slot Requests
>
> Hi, Chris:
>
> Thanks for sharing your thoughts for the past discussions.
> The reason that the previous Big-TLV proposal doesn't win the debates in past
> is that it has the same "key" definitions requirements for every possible big
> IS-
> IS TLV, as that in the current approach of MP-TLV solution.
>
> But, the above "key" definition for every possible big IS-IS TLV requirements
> DOESN'T EXIST now, then the updated Big-TLV proposal has the obvious
> advantage over the current MP-TLV solution.
> It's time to reevaluate the two approaches within the WG.
>
> The main challenge for the MP-TLV approach is that it still requires the
> specific
> "key" definition for each possible big IS-IS TLV, which is non-extensible,
> non-
> deployable/operational(considering its ambiguous declaration of "MP-TLV
> capabilities" is type independent instead).
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -----邮件原件-----
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
> 代表 Christian Hopps
> 发送时间: 2024年10月23日 10:57
> 收件人: Aijun Wang <wangai...@tsinghua.org.cn>
> 抄送: 【外部账号】Christian Hopps <cho...@chopps.org>; Yingzhen Qu
> <yingzhen.i...@gmail.com>; lsr-chairs <lsr-cha...@ietf.org>;draft-wang-lsr-
> isis-big-...@ietf.org; lsr <lsr@ietf.org>
> 主题: [Lsr] Re: It's time to find one general solution to Big-TLV problem Re:
> IETF 121 LSR Slot Requests
>
>
> Hi Aijun,
>
> [as-wg-member]: Perhaps you don't recall, but if you go review all the email
> threads and presentations/video you will see that I was a supporter of
> Huaimo's idea originally.
>
> [as-wg-member]: However, I also accepted that I was "in the rough" and the
> WG did not agree with using a new TLV for this problem. The WG has a
> different solution that you do not agree with, but that doesn't change the WG
> rough consensus.
>
> Thanks,
> Chris.
>
> Aijun Wang <wangai...@tsinghua.org.cn> writes:
>
> > 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
> > <cho...@chopps.org> 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
> > <wangai...@tsinghua.org.cn> 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
> > <cho...@chopps.org> 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" <wangai...@tsinghua.org.cn> 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
> >
> >
> >
> >
> >
> >
> >
> > 发件人: forwardingalgori...@ietf.org
> >
> > [mailto:forwardingalgori...@ietf.org]代表 Yingzhen
> > Qu
> >
> > 发送时间: 2024年10月12日 3:54
> >
> > 收件人: lsr <lsr@ietf.org>; lsr-chairs
> > <lsr-cha...@ietf.org>
> >
> > 主题: [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 lsr-cha...@ietf.org
> > 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 -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
