Hi Bruno, No, we are not going to document the behavior of every implementation for every TLV, sub-TLV, and sub-sub-TLV for you. We don’t have that kind of access nor would we get permission to do so. And we’re not young enough.
The point of clearly advertising capabilities is so that implementations have a scalable, automated way of providing what you ask for: information to network management. Modern networking is all about automation, and we are trying to push in that direction. Regards, Tony > On Nov 30, 2023, at 2:50 AM, bruno.decra...@orange.com wrote: > > 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> On Behalf Of Tony Li > Sent: Thursday, November 30, 2023 5:06 AM > To: Aijun Wang <wangai...@tsinghua.org.cn> > Cc: Yingzhen Qu <yingzhen.i...@gmail.com>; > draft-pkaneria-lsr-multi-...@ietf.org; lsr <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
