Les,
Another nice note. I don't think this is anywhere near as complicated as some
people are trying to make it.
John
On Wednesday, October 23, 2024 at 11:15:13 PM PDT, Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org> wrote:
Jie –
I’ll preface this by saying that if you were familiar with an implementation of
TLV processing, I don’t think you would be asking these questions – you would
be able to relate what has been discussed to code – and things would be obvious.
Which is one reason I have emphasized that the validity of the draft content is
supported by multiple implementations. We haven’t just conducted a “thought
experiment”.
We could use any TLV that is marked as potentially requiring MP support as an
example – but let’s stick with the neighbor TLV. It’s a good example and one
most folks are familiar with.
And let’s discuss this without considering MP – because this will demonstrate
why the addition of MP requires no additional specification for the neighbor
TLV.
When a node receives multiple neighbor TLVs from a given source, it has to
parse them for the tuple (systemid+pseudo-node id, link identifiers).
Why?
Because it has to build a database of links in the network. To build this
database it has to be able to identify one link from another - which requires
parsing the tuple. The database will then be used in a number of ways:
- It is used as part of the SPF calculation
- It is used by traffic engineering as the raw data to build constrained
paths
Etc.
It is also true that there are transient cases where the advertisement of a
neighbor may move from one LSP to another (for example if an additional sub-TLV
is required and there isn’t enough space in the LSP which has the existing
advertisement).
Because there is no guarantee that changes to multiple LSPs will be received
“atomically”, even in the absence of MP a receiver may temporarily have two
advertisements for the same link and it has to be able to recognize that state.
If the tuple were not sufficient to allow an implementation to differentiate
one neighbor advertisement from others it receives from the same source node,
then we would have a gap in the existing specifications which would already
have manifested itself as a problem in existing deployments.
So, what is referred to as a “key” in the draft isn’t new – and its use isn’t
new .
The only thing which is new is that when MP is enabled, it is now possible to
receive multiple TLVs for the same link outside of the transient case discussed
above. Implementations now have to treat the TLV content as “additive” whereas
previously they would treat the TLVs as “competing” and would have to choose
which one they would use and which one they would ignore. This is discussed
inhttps://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5
As for the case you mention below, where a non-key field which is present in
every neighbor TLV (metric) differs in two different TLVs which have the same
key, this is a pathological case which is also discussed in
https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5
All of this is already understood by implementations today because it is
necessary to properly process TLVs even in the absence of MP.
Existing specifications are clear as to what is a key for a given TLV. They
have to be or we would have interoperability problems even without MP.
If there actually is a case where this is not true, then it isn’t an MP problem
– it is a deficiency in the protocol independent of MP and would have to be
addressed as such. The correct thing to do would be to report it as an Errata
against the appropriate RFC.
Les
From: Dongjie (Jimmy) <jie.d...@huawei.com>
Sent: Wednesday, October 23, 2024 8:30 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Aijun Wang
<wangai...@tsinghua.org.cn>; '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: RE: [Lsr] Re: 答复: Re: It's time to find one general solution to
Big-TLV problem Re: IETF 121 LSR Slot Requests
Hi Les and Aijun,
I’d like to share some personal views on the “key” stuff.
For each IS-IS TLV/sub-TLV type , the “key” is embedded in the existing
information of the TLV, and it may consist of multiple fields. In my
understanding, for most of the TLVs the key fields are not explicitly specified.
Without clear specification of the key fields, it could still be easy to
differentiate two TLVs of the same type, as long as one of the key fields are
different (which can be apparent to implementers). However, it would be
relatively difficult to determine whether two TLVs of the same type can be
concatenated or not.
Section 4.1 of draft-ietf-lsr-multi-tlv uses TLV 22 as an example, it says:
“The key consists of the 7 octets of system ID and pseudonode number plus
the set of link identifiers which are present.”
Thus the “default metric” field is considered as non-key, but it will be
carried in every piece of the TLVs which need to be concatenated by the
receiver. Should the receiver compare the default metric field of the TLVs
received? If the TLVs have different “default metric” value, can they still be
concatenated? If so, which value should be used for the combined TLV?
For other TLVs, similar question can be raised.
I fully agree the key is codepoint specific, while it just shows that more
specification is needed to ensure consistent understanding about the processing
of the key and non-key fields in TLV concatenation. That is why during the WG
LC I suggested that this document either adds more specifications about the key
fields and processing for other TLVs (as it did for TLV 22 and 135 in section
4), alternatively it may consider to reduce the scope of the applicability to
the TLVs shown in the IANA section. Without clear specification of the key,
non-key and the processing for those TLVs, there will be risk in interoperation.
Best regards,
Jie
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, October 23, 2024 3:36 PM
To: Aijun Wang <wangai...@tsinghua.org.cn>; '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: RE: [Lsr] Re: 答复: Re: It's time to find one general solution to
Big-TLV problem Re: IETF 121 LSR Slot Requests
Ahhh…well…I am reminded of why I stopped engaging in these discussions.
Sigh…
If it were true ( as Aijun claims) that existing RFCs do not clearly define the
“key” for the codepoints defined in that document, then it would not be
possible for an implementation to correctly/reliably differentiate the objects
described in two different TLVs of the same type – even in the absence of MP.
This would mean that IS-IS is completely broken.
I am well past my quota for discussing nonsense – so no more from me.
Les
From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: Tuesday, October 22, 2024 11:31 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; '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:答复: Re: It's time to find one general solution to Big-TLV
problem Re: IETF 121 LSR Slot Requests
Hi, Les and members of the WG:
Let’s try to move forward and get more constructive results for the discussions.
First, I want to emphasize that I fully understand the current MP-TLV
solution(I think many experts have also understood), and know the
mentioned“key” fields are existing(or optional existing) in the current
encoding of each IS-IS TLV.
But, as mentioned by Les,“What constitutes a key is codepoint specific”, and
there is no any RFC document such information.
Current MP-TLV proposal gives such information only (“What constitutes a key”)
for two TLVs(“IS-Neighbor TLVs“ and“Prefix Reachability TLV“)，but none for
others( for example “BFD Enabled TLV“ that provided by Les in this mail as
another possible big IS-IS TLV example), let alone all the possible big IS-IS
TLVs.
Lacking the definition of“What constitutes a key” CANNOT certainly achieve the
aim of “treating two TLVs for the same object as additive rather than as
replacements for each other”, in other words, glue the sliced IS-IS TLVs
together.
The last sentence is my main argue point for the current MP-TLV proposal.
Best Regards
Aijun Wang
China Telecom
,
发件人:forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]代表 Les
Ginsberg (ginsberg)
发送时间: 2024年10月23日 13:23
收件人: 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: 答复: Re: It's time to find one general solution to Big-TLV problem
Re: IETF 121 LSR Slot Requests
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
seehttps://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 in
https://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 in
https://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 tohttps://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 tolsr-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 tolsr-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
