[Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-29 Thread Aijun Wang 
Hi, Tony:

 

If the MP-TLV support capability declaration  doesn’t mean support all relevant 
TLVs, and conform to the draft can’t assure the interoperability, then, what 
the purpose of this draft?

If you persist this direction, as proposed by Bruno, I think that documents the 
capabilities(includes the definition of the key) for every TLV in one Yang 
file(draft-isis-pics-multi-TLV”?) maybe more better.

The operator can compare such yang files from different vendor, and if they 
support the multipart of the same TLV, and the key is same, then the operator 
can safely enable the sending and receiving of the multi-part of this TLV.

 

Or else, we should think other solution to solve this issue.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Tony 
Li
发送时间: 2023年11月29日 0:49
收件人: Aijun Wang 
抄送: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
主题: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

 

Hi Aijun,

 

 





On Nov 26, 2023, at 7:05 PM, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Some additional questions:

 

The draft say “The contents of a multi-part TLV MUST be processed as if they 
were concatenated. If the internals of the TLV contain key information, then 
replication of the key information should be taken to indicate that subsequent 
data MUST be processed as if the subsequent data were concatenated after a 
single copy of the key information.”

 

1) How to deal with the TLV that has no key information? 

 

 

That’s the easiest case: the content between instances is not correlated, so 
each TLV can be individually processed independently.

 





2) And, to support multi-part TLV,  the key information (if the TLV has 
such information) for each applied TLV must also be standardized, or else, 
there will be error.

The draft wants to just avoid to tackle such issues(as stated in draft “Having 
inconsistent information in different parts of a MP-TLV is an error and is out 
of scope for this document.), but it should be the MUST part of the solution. 

 

 

I respectfully disagree. Having a single RFC that sorts through all of that is 
wholly unwieldy and guaranteed to be highly erroneous.  It’s far better to 
write separate documents that can be individually and carefully crafted and 
reviewed.





 

Or else, how to assure the interoperability?

 

 

Interoperability is never assured by documents. Careful thought, coding, and 
testing are required. This has not changed.

 

T

 





 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:  <mailto:forwardingalgori...@ietf.org> forwardingalgori...@ietf.org [ 
<mailto:forwardingalgori...@ietf.org> mailto:forwardingalgori...@ietf.org] 代表 
Aijun Wang
发送时间: 2023年11月24日 16:11
收件人: 'Yingzhen Qu' < <mailto:yingzhen.i...@gmail.com> yingzhen.i...@gmail.com>; 
 <mailto:draft-pkaneria-lsr-multi-...@ietf.org> 
draft-pkaneria-lsr-multi-...@ietf.org; 'lsr' < <mailto:lsr@ietf.org> 
lsr@ietf.org>
主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:  <mailto:forwardingalgori...@ietf.org> forwardingalgori...@ietf.org [ 
<mailto:forwardingalgori...@ietf.org> mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人:  <mailto:draft-pkaneria-lsr-multi-...@ietf.org> 
draft-pkaneria-lsr-multi-...@ietf.org; lsr < <mailto:lsr@ietf.org> lsr@ietf.org>
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv:  
<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-24 Thread Aijun Wang 
Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
 

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr