Hi authors, I’ve read both the draft and the recent discussion on the list. IMO Bruno’s concern is reasonable.
As MP-TLV is not the default behavior for all TLVs specified in existing RFCs, operator has to be careful when enabling the MP-TLV behavior for existing TLVs, especially for TLVs which are related to IGP route computation. While the risk may be less for TLVs which are not related to IGP computation. Thus it would be helpful if the document could separate the default behavior for TLVs related to route computation, and TLVs which are not related to route computation. Another point is whether the MP-TLV mechanism should be considered as short term or long term approach. If it is just a short term mechanism to accommodate existing implementations, do we need a long term approach? Best regards, Jie From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com Sent: Thursday, November 30, 2023 6:51 PM To: Tony Li <tony...@tony.li>; draft-pkaneria-lsr-multi-...@ietf.org Cc: Yingzhen Qu <yingzhen.i...@gmail.com>; lsr <lsr@ietf.org>; Aijun Wang <wangai...@tsinghua.org.cn> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi authors, Ø We are documenting existing behavior, codifying what we believe most implementations are already doing Could the authors share with the WG what are those existing behaviors (TLVs supporting MP-TLV) and implementations? Many be this is a reason for some disconnect as - On one hand, if all implementations already support MP-TLV for all TLVs indicated in this draft, then there is less deployment issues/risks. (Although there are still some risks as not all nodes will get the support at the same time, in particular for legacy platforms which will lack the MP TLV support for years) - On the other hand, if only a couple of implementations support MP-TLV for a couple of TLVs, the risk seems much higher. If this is not known (1), we can’t assume that this is safe and deployable without risk. (1) or not sharable for some reasons, although a priori vendors should be proud of their innovations Ø 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? Same question with :s/draft/capability Although I believe I had already raised that point. Regards, --Bruno From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Tony Li Sent: Thursday, November 30, 2023 5:06 AM To: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi Aijun, 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? We are documenting existing behavior, codifying what we believe most implementations are already doing, and documenting the direction that we think we should be going. 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. Then YANG model for reporting capabilities is a mostly orthogonal document. 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. That alone is not sufficient. Or else, we should think other solution to solve this issue. There is no other solution. Regards, Tony ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
