Hi Les, *> We can only do our best to advertise what the configuration requires us to advertise,*
Let's zoom on this important statement as if this would be really the case I don't think we would have this discussion. The issue seems to be that the configuration may enable flooding various dynamic data with unknown size restrictions (at the cfg point/moment). So pushing the issue back to the operator who enabled such distributions seems not proper if that causes network wide issues - especially on nodes which do not support MP-TLVs. If your point however is that injection of MP-TLV MUST be explicitly enabled under ISIS cfg on all nodes after the operator is 100% sure that all nodes can handle it - I do not see an issue. So pls kindly clarify. Many thx, Robert On Tue, Sep 3, 2024 at 9:15 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > 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]> wrote: > > Speaking as WG member: > > > On Sep 2, 2024, at 17:42, Les Ginsberg (ginsberg) <[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]> > >> Sent: Monday, September 2, 2024 9:06 AM > >> To: [email protected] > >> Cc: Christian Hopps <[email protected]>; Les Ginsberg (ginsberg) > >> <[email protected]>; Yingzhen Qu <[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) > >> > >> > >> > >>> On Sep 2, 2024, at 11:38, [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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
