Hi Robert,
From: Robert Raszuk <[email protected]>
Sent: Tuesday, September 10, 2024 3:21 PM
To: DECRAENE Bruno INNOV/NET <[email protected]>
Cc: Tony Li <[email protected]>; Les Ginsberg <[email protected]>; Les Ginsberg
<[email protected]>; Yingzhen Qu <[email protected]>;
lsr-chairs <[email protected]>; lsr <[email protected]>
Subject: Re: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
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.
I would not call it “cool” either but it allows network operator to avoid
interop issues for TLVs with newly defined MP-TLV support/extension.
At the cost of not allowing the network operator to use MP-TLV for any of those
TLVs. (so not cool, but at least a way to be safe which is my top priority.
IMO it needs to be per TLV irrespective if enforced by this draft or by private
negotiations with vendors.
I agree that per-TLV is better as it would better allow deployment on a per TLV
basis. But I think that the current SHOULD is reasonable.
Another path would be for draft-ietf-lsr-multi-tlv to mandate MP-TLV support
for all TLVs supported by the implementation. That way a single control is
enough. But I feel that it would be unlikely as implementors have a preference
for only implementing what they want.
Thanks,
--Bruno
Thx,
Robert
On Tue, Sep 10, 2024 at 2:59 PM
<[email protected]<mailto:[email protected]>> wrote:
Hi Tony,
From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf
Of Tony Li
Sent: Monday, September 9, 2024 7:20 PM
To: DECRAENE Bruno INNOV/NET
<[email protected]<mailto:[email protected]>>
Cc: Les Ginsberg <[email protected]<mailto:[email protected]>>; Les Ginsberg
<[email protected]<mailto:[email protected]>>;
Yingzhen Qu <[email protected]<mailto:[email protected]>>;
lsr-chairs <[email protected]<mailto:[email protected]>>; lsr
<[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,
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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
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]
