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. 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. Thanks, Yingzhen On Tue, Sep 3, 2024 at 7:53 AM Acee Lindem <acee.i...@gmail.com> wrote: > Speaking as WG member: > > > On Sep 2, 2024, at 17:42, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > 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 <cho...@chopps.org> > >> Sent: Monday, September 2, 2024 9:06 AM > >> To: bruno.decra...@orange.com > >> Cc: Christian Hopps <cho...@chopps.org>; Les Ginsberg (ginsberg) > >> <ginsb...@cisco.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; lsr > >> <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org> > >> 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, bruno.decra...@orange.com 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
