Yingzhen – (Bruno – I hope you are reading this as well – since my reply is relevant to some of your comments.)
From: Yingzhen Qu <[email protected]> Sent: Tuesday, September 3, 2024 11:36 AM To: Acee Lindem <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps <[email protected]>; Bruno Decraene <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Speaking as a WG member. The following text is in section 7.3: " Implementations SHOULD NOT send multiple TLVs unless MP-TLV is applicable to the TLV and the amount of information which is required to be sent exceeds the capacity of a single TLV. For example, when additional space is required in an existing TLV, as long as there is space in the TLV, information SHOULD NOT be split into multiple TLVs. If there is no space in the current LSP to fit the now larger TLV, the TLV SHOULD be moved to a new LSP. " To me, as a developer, it is clear that MP-TLV SHOULD NOT be used unless this TLV is too big to even fit into one LSP . If there is a configuration knob, it has to be enabled. [LES:] I think you are agreeing with the text, but to be clear… This text is only applicable when the use of MP-TLVs has been enabled. It is not trying to say that MP-TLVs can be sent when they have not been enabled. Given that, we are following the old axiom of “be strict in what you send and generous in what you receive”. So, don’t send two TLVs when one would do – but if an implementation receives two TLVs it should process them even if the info could have been sent in one TLV. This should not be controversial – it is following well established practice. And it is NOT enabling the sending of MP-TLVs when they have been disabled by the operator. So, “yes” if you or I were writing code, we would do our best to never send two TLVs when one would do. But, if some implementation falls short of this goal, receivers should not reject otherwise valid information simply because it was not sent in the optimal way. An updated version of the draft will add text clarifying these points . However, I'm wondering whether the following text from Section 7.1 is challenging to operators: " Therefore, diligence is still required on the part of the operator to ensure that configurations which require the sending of MP-TLV for a given codepoint are not introduced on any node in the network until all nodes in the network support MP-TLV for the relevant codepoints. " Assuming an operator receives an alarm indicating that MP-TLV is triggered, I think adjusting the configuration can be challenging. Please correct me if I'm wrong. [LES:] Deploying MP-TLV has to be done carefully. If a mistake is made, the alarms alert the operator to that fact. What action to take may not – as you suggest – be easy to decide. There are some easy cases – such as the network is fully MP-TLV capable, but the operator forgot to enable MP-TLV on one node before adding config that requires more than 255 bytes of info to be sent. But there are also difficult cases such as the introduction of config that requires more than 255 bytes to be sent before MP-TLV support is fully deployed. How to change the config so that MP-TLV is not required may not be trivial. But the protocol cannot prevent this. We can only do our best to advertise what the configuration requires us to advertise, adhere to the enablement restrictions, and report occurrences where constraints have been violated. Are you hinting that there is something else that should be done?? If so, please make a suggestion. Les Thanks, Yingzhen On Tue, Sep 3, 2024 at 7:53 AM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Speaking as WG member: > On Sep 2, 2024, at 17:42, Les Ginsberg (ginsberg) > <[email protected]<mailto:[email protected]>> wrote: > > Chris - > > I am continuing to think on this - based both on Bruno's input and now your > input. > > However, this would seem to potentially put the WG in the role of being asked > to pass judgment on whether a given implementation's configuration options > are conformant or not. > This is not a role I want to play - nor is it a responsibility I think the WG > should take on. I feel this should be added to the “Management Considerations” though it should not be a “MUST”. Now should it be a “SHOULD” or a “MAY”? I don’t have a strong opinion although I lean toward “MAY” since we’ve gotten along fine without it for so long and it doesn’t make sense to try mandate additional functionality. Thanks, Acee > > I would be interested in your thoughts in this regard (with or without your > WG chair hat on). > > Thanx. > > Les > >> -----Original Message----- >> From: Christian Hopps <[email protected]<mailto:[email protected]>> >> Sent: Monday, September 2, 2024 9:06 AM >> To: [email protected]<mailto:[email protected]> >> Cc: Christian Hopps <[email protected]<mailto:[email protected]>>; Les >> Ginsberg (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) >> >> >> >>> On Sep 2, 2024, at 11:38, >>> [email protected]<mailto:[email protected]> wrote: >>> >>> It is not within the purview of an RFC to mandate that an implementation >> have a particular knob. >>> [Bruno] >>> • According to which document /rule? >> >> [as wg-member] >> >> Regardless of whether we choose to add this requirement, I'm pretty sure it's >> fine to mandate that something be configurable (e.g., disable/enable) in an >> RFC. I haven't done a search but I definitely have seen this in other >> documents. >> >> What this would be saying is that in order to claim support for RFCXXXX one >> must have the given configuration option. >> >> Thanks, >> Chris. >> [as wg-member]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
