Hi Bruno,
> If you are ok with a required _*single*_ configuration controls to
enable/disable generation of MP-TLVs
> (for the TLVs extended by this draft) we are good
How would you see this config knob to look if this would not be per TLV ?
#router isis
disable MP-TLV as defined in rfcxxxx
does not sound too cool.
IMO it needs to be per TLV irrespective if enforced by this draft or by
private negotiations with vendors.
Thx,
Robert
On Tue, Sep 10, 2024 at 2:59 PM <[email protected]> wrote:
> Hi Tony,
>
>
>
> *From:* Tony Li <[email protected]> *On Behalf Of *Tony Li
> *Sent:* Monday, September 9, 2024 7:20 PM
> *To:* DECRAENE Bruno INNOV/NET <[email protected]>
> *Cc:* Les Ginsberg <[email protected]>; Les Ginsberg <ginsberg=
> [email protected]>; Yingzhen Qu <[email protected]>;
> lsr-chairs <[email protected]>; lsr <[email protected]>
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024
> - 7/15/2024)
>
>
>
> Hi Bruno,
>
>
>
> As you know, there are several TLVs that have been MP-TLV for a very long
> time (e.g. ROUTER CAPABILITY). Having these be MP is a practical
> operational necessity already today. Disabling this on any node would
> likely break any network that has some fairly common features (e.g.
> FlexAlgo) enabled.
>
>
>
> [Bruno] I meant for the newly defined MP-TLV. The one for which MP
> handling is changed by this document. TLVs which have been defined with
> MP-TLV from day one do not create interop issue. It’s the change of
> behavior when handling TLV X of a new implementation which create an
> interop issue with the handling of TLV X from old implementations.
>
> If it’s just a wording issue, I’m confident that someone can craft the
> right wording.
>
>
>
> What is the point of a knob that cannot be turned off?
>
> [Bruno] I agree that the point is to be able to turn it off.
>
>
>
>
>
> Then you’re back to requiring per-TLV configuration. No thanks.
>
>
>
> [Bruno2] Nope. I’ve written down my proposed change and it does not
> include that. If you are ok with a required _*single*_ configuration
> controls to enable/disable generation of MP-TLVs (for the TLVs extended by
> this draft) we are good. Per-TLV configuration is out of scope of this
> thread.
>
>
>
> Also, I don’t think we’re trying to create any “newly defined MP-TLV”. The
> point is to codify what has been done and create a default path moving
> forward.
>
>
>
> [Bruno2] RFC5305 does not support MP-TLV for TLV 22 and
> draft-ietf-lsr-multi-tlv acknowledges that.
>
> Specification of MP-TLV for TLV 22 is introduced and defined in
> draft-ietf-lsr-multi-tlv
>
>
>
> --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]
