Hi Jimmy, Thank you for your comments.
The whole point of this document is to broadly define the MP-TLV rules for all appropriate TLVs. Regards, Tony > On Sep 12, 2024, at 1:00 AM, Dongjie (Jimmy) > <[email protected]> wrote: > > Hi Bruno, Tony, Les and all, > > I fully understand the concern about interoperability, and would support > approaches which can help to improve interoperability. > > In addition to making the text more strict by using “MUST”, I’d like to > mention other points which can help to mitigate the risk for operators. > > In my view the main purpose of this document is to specify the usage of the > Multi-part TLV approach to a few existing TLVs which are likely to exceed the > limitation of 255 octets, such as TLV 22 and TLV 135. Although these two TLVs > are just described as examples in the draft, the specifications about their > key fields and the sending/receiving procedure are clear. With the new router > capability information and operator’s control, their interoperability could > be achieved. > > While for other TLVs as listed in the IANA with “Y” in the MP column, their > key fields and the procedure are not explicitly specified in this document. > IMO this leaves uncertainty on whether, when and how they will be > implemented, and this would increase the possibility of interoperability > issues for implementations which claim to support this document. And this > cannot be reflected by the new router capability information. Due to such > uncertainty, operators may choose not to use Multi-part TLV even for TLV 22 > and 135. > > Thus if the purpose of the document is to promote the usage of Multi-part > approach for TLVs which already show the needs, maybe it is better to narrow > down the scope of this document and focus on the specification for a smaller > group of TLVs. > > Best regards, > Jie > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected]] > Sent: Tuesday, September 10, 2024 10:41 PM > To: Tony Li <[email protected] <mailto:[email protected]>> > Cc: Les Ginsberg <[email protected] <mailto:[email protected]>>; Yingzhen > Qu <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>>; lsr-chairs <[email protected] > <mailto:[email protected]>> > Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > Hi Tony, > > From: Tony Li <[email protected] <mailto:[email protected]>> On > Behalf Of Tony Li > Sent: Tuesday, September 10, 2024 4:15 PM > To: DECRAENE Bruno INNOV/NET <[email protected] > <mailto:[email protected]>> > Cc: Les Ginsberg <[email protected] <mailto:[email protected]>>; Yingzhen > Qu <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>>; lsr-chairs <[email protected] > <mailto:[email protected]>> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > Hi Bruno, > > [Bruno2] I agree that everyone should already want to interoperable. But the > unfortunate reality is that not everyone does. I believe that RC3107 is a > relatively well-known example: some implementors have deliberately not > implemented all (implicit) MUST at the cost of interop issues for network > operators. Some details > inhttps://datatracker.ietf.org/doc/html/rfc8277#section-1 I have other more > recent examples but I’d rather avoid pointing to specific implementations. > > > So you’re admitting that ‘MUST’ doesn’t guarantee interoperability. So why > fight about it? > > MUST does not guarantee interoperability for implementations which are not > compliant with the RFC. (i.e., implementation which does not respect the > MUST. By design or bugs) > Implementations which are compliant with RFC are interoperable. > > --Bruno > > T > > > ____________________________________________________________________________________________________________ > 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 -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
