Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Acee Lindem (acee)]

Speaking as document shepherd and WG member:

Hi John, Qin, and Dhruv,

See a couple inlines.

From: Lsr  on behalf of Dhruv Dhody 
Date: Thursday, August 25, 2022 at 7:02 AM
To: Qin Wu 
Cc: John Scudder , 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "lsr@ietf.org" 

Subject: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin, John,

I have added my comments for two issues, please see inline (look for Dhruv:)


On Thu, Aug 25, 2022 at 2:52 PM Qin Wu 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi, John:
Thanks for your valuable AD review. We have incorporate your comments into 
draft-ietf-lsr-pce-discovery-security-support-10.
Regarding the issues your raised below, please reply inline below.

-Qin (on behalf of authors)
发件人: John Scudder [mailto:j...@juniper.net]
发送时间: 2022年8月18日 8:41
收件人: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org;
 lsr@ietf.org
主题: AD review of draft-ietf-lsr-pce-discovery-security-support-09

Dear Authors,

Thanks for you patience as this document sat in my queue for too long. :-( 
Here’s my review.

I’ve supplied my comments in the form of an edited copy of the draft. Minor 
editorial suggestions I’ve made in place without further comment, more 
substantive comments are done in-line and prefixed with “jgs:”. You can use 
your favorite diff tool to review them; I’ve attached a PDF of the iddiff 
output for your convenience if you’d like to use it. I’ve also pasted a 
traditional diff below in case you want to use it for in-line reply. I’d 
appreciate feedback regarding whether you found this a useful way to receive my 
comments as compared to a more traditional numbered list of comments with 
selective quotation from the draft.

Thanks,

—John


--- draft-ietf-lsr-pce-discovery-security-support-09.txt2022-08-17 
15:35:47.0 -0400
+++ draft-ietf-lsr-pce-discovery-security-support-09-jgs-comments.txt   
2022-08-17 20:37:48.0 -0400
@@ -13,14 +13,14 @@
   21 August 2021


-IGP extension for PCEP security capability support in the PCE discovery
+IGP extension for PCEP security capability support in PCE discovery
 draft-ietf-lsr-pce-discovery-security-support-09

 Abstract

When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a
-   server participating in IGP, its presence and path computation
+   server participating in the IGP, its presence and path computation
capabilities can be advertised using IGP flooding.  The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for
@@ -28,10 +28,10 @@
method to advertise PCEP security (e.g., Transport Layer Security
(TLS), TCP Authentication Option (TCP-AO)) support capability.

-   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
+   This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV
that can be announced as an attribute in the IGP advertisement to
distribute PCEP security support information.  In addition, this
-   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
+   document updates RFC 5088 and RFC 5089 to allow advertisement of a Key
ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
movement of the IANA "PCE Capability Flags" registry.
@@ -100,7 +100,7 @@
 1.  Introduction

As described in [RFC5440], PCEP communication privacy is one
-   importance issue, as an attacker that intercepts a Path Computation
+   important issue, as an attacker that intercepts a Path Computation
Element (PCE) message could obtain sensitive information related to
computed paths and resources.

@@ -114,14 +114,14 @@
 Internet-Draft   IGP discovery for PCEP Security August 2021


-   Among the possible solutions mentioned in these documents, Transport
+   Among the possible solutions mentioned in that document, Transport
Layer Security (TLS) [RFC8446] provides support for peer
authentication, and message encryption and integrity while TCP
Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms
for TCP-AO [RFC5926] offer significantly improved security for
applications using TCP.  As specified in section 4 of [RFC8253], in
order for a Path Computation Client (PCC) to establish a connection
-   with a PCE server using TLS or TCP-AO, PCC needs to know whether PCE
+   with a PCE server using TLS or TCP-AO, the PCC needs to know whether the PCE
server supports TLS or TCP-AO as a secure transport.

[RFC5088] and [RFC5089] define a method to advertise path computation
@@ -129,10 +129,10 @@
However 

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Dhruv Dhody]

Hi Qin, John,

I have added my comments for two issues, please see inline (look for Dhruv:)


On Thu, Aug 25, 2022 at 2:52 PM Qin Wu 
wrote:

> Hi, John:
>
> Thanks for your valuable AD review. We have incorporate your comments into
> draft-ietf-lsr-pce-discovery-security-support-10.
>
> Regarding the issues your raised below, please reply inline below.
>
>
>
> -Qin (on behalf of authors)
>
> *发件人:* John Scudder [mailto:j...@juniper.net]
> *发送时间:* 2022年8月18日 8:41
> *收件人:* draft-ietf-lsr-pce-discovery-security-supp...@ietf.org;
> lsr@ietf.org
> *主题:* AD review of draft-ietf-lsr-pce-discovery-security-support-09
>
>
>
> Dear Authors,
>
> Thanks for you patience as this document sat in my queue for too long. :-(
> Here’s my review.
>
> I’ve supplied my comments in the form of an edited copy of the draft.
> Minor editorial suggestions I’ve made in place without further comment,
> more substantive comments are done in-line and prefixed with “jgs:”. You
> can use your favorite diff tool to review them; I’ve attached a PDF of the
> iddiff output for your convenience if you’d like to use it. I’ve also
> pasted a traditional diff below in case you want to use it for in-line
> reply. I’d appreciate feedback regarding whether you found this a useful
> way to receive my comments as compared to a more traditional numbered list
> of comments with selective quotation from the draft.
>
> Thanks,
>
> —John
>
>
>
> --- draft-ietf-lsr-pce-discovery-security-support-09.txt2022-08-17
> 15:35:47.0 -0400
> +++ draft-ietf-lsr-pce-discovery-security-support-09-jgs-comments.txt
> 2022-08-17 20:37:48.0 -0400
> @@ -13,14 +13,14 @@
>21 August 2021
>
>
> -IGP extension for PCEP security capability support in the PCE discovery
> +IGP extension for PCEP security capability support in PCE discovery
>  draft-ietf-lsr-pce-discovery-security-support-09
>
>  Abstract
>
> When a Path Computation Element (PCE) is a Label Switching Router
> (LSR) participating in the Interior Gateway Protocol (IGP), or even a
> -   server participating in IGP, its presence and path computation
> +   server participating in the IGP, its presence and path computation
> capabilities can be advertised using IGP flooding.  The IGP
> extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
> to advertise path computation capabilities using IGP flooding for
> @@ -28,10 +28,10 @@
> method to advertise PCEP security (e.g., Transport Layer Security
> (TLS), TCP Authentication Option (TCP-AO)) support capability.
>
> -   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
> +   This document defines capability flag bits for the PCE-CAP-FLAGS
> sub-TLV
> that can be announced as an attribute in the IGP advertisement to
> distribute PCEP security support information.  In addition, this
> -   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
> +   document updates RFC 5088 and RFC 5089 to allow advertisement of a Key
> ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
> RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
> movement of the IANA "PCE Capability Flags" registry.
> @@ -100,7 +100,7 @@
>  1.  Introduction
>
> As described in [RFC5440], PCEP communication privacy is one
> -   importance issue, as an attacker that intercepts a Path Computation
> +   important issue, as an attacker that intercepts a Path Computation
> Element (PCE) message could obtain sensitive information related to
> computed paths and resources.
>
> @@ -114,14 +114,14 @@
>  Internet-Draft   IGP discovery for PCEP Security August 2021
>
>
> -   Among the possible solutions mentioned in these documents, Transport
> +   Among the possible solutions mentioned in that document, Transport
> Layer Security (TLS) [RFC8446] provides support for peer
> authentication, and message encryption and integrity while TCP
> Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms
> for TCP-AO [RFC5926] offer significantly improved security for
> applications using TCP.  As specified in section 4 of [RFC8253], in
> order for a Path Computation Client (PCC) to establish a connection
> -   with a PCE server using TLS or TCP-AO, PCC needs to know whether PCE
> +   with a PCE server using TLS or TCP-AO, the PCC needs to know whether
> the PCE
> server supports TLS or TCP-AO as a secure transport.
>
> [RFC5088] and [RFC5089] define a method to advertise path computation
> @@ -129,10 +129,10 @@
> However these specifications lack a method to advertise PCEP security
> (e.g., TLS) support capability.
>
> -   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
> +   This document defines capability flag bits for the PCE-CAP-FLAGS
> sub-TLV
> that can be announced as attributes in the IGP advertisement to
>   

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Inline: GV>

From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV Capability’ 
flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist? 


A system that supported MP-TLVs would not be able to determine that there were 
other systems in the area that did not support MP-TLVs.  The system might then 
advertise MP-TLVs and they would be misinterpreted or cause system crashes in 
the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy router 
has no support for handling MP-TLV, then yes, things get misinterpreted. There 
is nothing wrong with that, is there? Do you have an example where things go 
wrong? 

If we want to introduce MP-TLVs, that change would warrant the existence of the 
flag.  

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS behave 
better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing with a 
binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends flip-flopping 
(set/unset/set/unset/etc) of this flag? 

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV ‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct the flag during 
each single upgrade. 

GV> Unfortunately I remain to have troubles understanding the value "Multi-part 
TLV Capability’ flag brings to an ISIS network. 
  * Without flag it is indeed uncertain if area wide mp-tlv is supported 
(sub-optimal). 
  * but with catch all MP-TLV flag I am not sure we improve ISIS operation: 
  ** Who guarantees that the flag is set correctly on all systems at all times
  ** Maybe all systems falls back to advertise single TLV because another 
(legacy?) system advertise a wrong flag  (sub-optimal)
  ** Legacy system with MP-TLV support gets upgraded and now supports 
additional TLVs but not with MP-TLV...  ?manual intervention? (sub-optimal)
  ** what, when, how, why, who sets the MP-TLV flag? What with flapping of 
MP-TLV flag (undefined)

G/

Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

Speaking as WG member:

Hi Gunder, Tony, Les, 

I'm also not a fan of the Multi-Part TLV Capability flag. While the intent of 
the draft is to encourage multi-part TLV advertisement and usage, the addition 
of this flag and the requirement for advertisement will most likely have the 
opposite effect. Given that IS-IS implementations are already advertising 
multi-part TLVs but none are advertising the proposed capability flag, 
implementation of the draft as currently written would inhibit Multi-Part TLV 
usage and be a step backwards. Of course, we know implementations that are 
already advertising these multi-part TLVs will most likely ignore the 
recommendation and continue to advertise them even when not all IS-IS routers 
within the scope of the Multi-Part TLV advertise the capability. 

Rather, I propose that the draft eliminates the capability flag and introduces 
a recommended configuration parameter that would allow Multi-Part TLVs to be 
suppressed. The recommended default would be FALSE. This would provide an out 
if these Multi-Part TLVs did, in fact, have dire consequences. 

Thanks,
Acee

On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - 
BE/Antwerp)"  
wrote:

Inline: GV>

From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV 
Capability’ flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist? 


A system that supported MP-TLVs would not be able to determine that there 
were other systems in the area that did not support MP-TLVs.  The system might 
then advertise MP-TLVs and they would be misinterpreted or cause system crashes 
in the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy 
router has no support for handling MP-TLV, then yes, things get misinterpreted. 
There is nothing wrong with that, is there? Do you have an example where things 
go wrong? 

If we want to introduce MP-TLVs, that change would warrant the existence of 
the flag.  

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS 
behave better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing 
with a binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends 
flip-flopping (set/unset/set/unset/etc) of this flag? 

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct the flag during 
each single upgrade. 

GV> Unfortunately I remain to have troubles understanding the value 
"Multi-part TLV Capability’ flag brings to an ISIS network. 
  * Without flag it is indeed uncertain if area wide mp-tlv is supported 
(sub-optimal). 
  * but with catch all MP-TLV flag I am not sure we improve ISIS operation: 
  ** Who guarantees that the flag is set correctly on all systems at all 
times
  ** Maybe all systems falls back to advertise single TLV because another 
(legacy?) system advertise a wrong flag  (sub-optimal)
  ** Legacy system with MP-TLV support gets upgraded and now supports 
additional TLVs but not with MP-TLV...  ?manual intervention? (sub-optimal)
  ** what, when, how, why, who sets the MP-TLV flag? What with flapping of 
MP-TLV flag (undefined)

G/

Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Les Ginsberg (ginsberg)]

Having the ability to “see” what a given box supports is certainly useful – but 
the question is whether sending such information in LSPs is the right way to do 
it.
The information cannot be used be used by the routers themselves.

Better ways to make this available to operators include:

On box show commands
Retrieval via management apps/models
Vendor documentation

Sending this in LSPs violates something many of us on this thread have argued 
against for years: “Don’t send information which isn’t used by the protocol.”

   Les


From: Lsr  On Behalf Of Robert Raszuk
Sent: Thursday, August 25, 2022 9:17 AM
To: Acee Lindem (acee) 
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Tony Li ; lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

All,

I am actually finding this capability useful. If for nothing else then to help 
the operator to see what is going on in the area. On any node simple show 
command will clearly show who is willing and capable to receive MP-TLVs and who 
is not.

Analogy to including hostnames Tony brought here as an example is spot on and 
along the same lines.

Of course how node uses that info could be discussed further. I would also not 
object to put that capability into a separate document.

Thx,
R.





On Thu, Aug 25, 2022 at 6:06 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as WG member:

Hi Gunder, Tony, Les,

I'm also not a fan of the Multi-Part TLV Capability flag. While the intent of 
the draft is to encourage multi-part TLV advertisement and usage, the addition 
of this flag and the requirement for advertisement will most likely have the 
opposite effect. Given that IS-IS implementations are already advertising 
multi-part TLVs but none are advertising the proposed capability flag, 
implementation of the draft as currently written would inhibit Multi-Part TLV 
usage and be a step backwards. Of course, we know implementations that are 
already advertising these multi-part TLVs will most likely ignore the 
recommendation and continue to advertise them even when not all IS-IS routers 
within the scope of the Multi-Part TLV advertise the capability.

Rather, I propose that the draft eliminates the capability flag and introduces 
a recommended configuration parameter that would allow Multi-Part TLVs to be 
suppressed. The recommended default would be FALSE. This would provide an out 
if these Multi-Part TLVs did, in fact, have dire consequences.

Thanks,
Acee

On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - 
BE/Antwerp)" mailto:lsr-boun...@ietf.org> on behalf of 
gunter.van_de_ve...@nokia.com> wrote:

Inline: GV>

From: Tony Li mailto:tony1ath...@gmail.com>> On 
Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV 
Capability’ flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist?


A system that supported MP-TLVs would not be able to determine that there 
were other systems in the area that did not support MP-TLVs.  The system might 
then advertise MP-TLVs and they would be misinterpreted or cause system crashes 
in the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy 
router has no support for handling MP-TLV, then yes, things get misinterpreted. 
There is nothing wrong with that, is there? Do you have an example where things 
go wrong?

If we want to introduce MP-TLVs, that change would warrant the existence of 
the flag.

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS 
behave better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing 
with a binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends 
flip-flopping (set/unset/set/unset/etc) of this flag?

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct the flag 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Przygienda]

Given the realities of deploying something like this I am all for
advertisement of what I'll call here the "multi-TLV-compliance" flag
(assuming we agree that capability implies a change in procedures on
reception from other nodes which this draft does not).  Being able to see
that a customer network deployed something that is _not_ compliant with the
RFC (even potentially) can save a lot of head scratching and ghost chasing
given that nodes receiving multi-part-TLVs and not processing them
correctly will exhibit most vexing behavior that is not observable on LSDB
or any of the other tools we normally use.

=--- tony

On Thu, Aug 25, 2022 at 6:07 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
> Hi Gunder, Tony, Les,
>
> I'm also not a fan of the Multi-Part TLV Capability flag. While the intent
> of the draft is to encourage multi-part TLV advertisement and usage, the
> addition of this flag and the requirement for advertisement will most
> likely have the opposite effect. Given that IS-IS implementations are
> already advertising multi-part TLVs but none are advertising the proposed
> capability flag, implementation of the draft as currently written would
> inhibit Multi-Part TLV usage and be a step backwards. Of course, we know
> implementations that are already advertising these multi-part TLVs will
> most likely ignore the recommendation and continue to advertise them even
> when not all IS-IS routers within the scope of the Multi-Part TLV advertise
> the capability.
>
> Rather, I propose that the draft eliminates the capability flag and
> introduces a recommended configuration parameter that would allow
> Multi-Part TLVs to be suppressed. The recommended default would be FALSE.
> This would provide an out if these Multi-Part TLVs did, in fact, have dire
> consequences.
>
> Thanks,
> Acee
>
> On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia -
> BE/Antwerp)"  gunter.van_de_ve...@nokia.com> wrote:
>
> Inline: GV>
>
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, August 24, 2022 5:26 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
> Hi Gunter,
>
> I am having troubles understanding the value of ‘The Multi-part TLV
> Capability’ flag.
> What would break if ‘Multi-part TLV Capability’ flag would not exist?
>
>
> A system that supported MP-TLVs would not be able to determine that
> there were other systems in the area that did not support MP-TLVs.  The
> system might then advertise MP-TLVs and they would be misinterpreted or
> cause system crashes in the systems that did not support them.
>
> GV> crashes? I really hope that is not happening.
> GV> When a legacy router receives MP-TLVs from another system and
> legacy router has no support for handling MP-TLV, then yes, things get
> misinterpreted. There is nothing wrong with that, is there? Do you have an
> example where things go wrong?
>
> If we want to introduce MP-TLVs, that change would warrant the
> existence of the flag.
>
> GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS
> behave better
>
> I dispute that a binary flag warrants the word ‘complexity’.
>
> GV>  living without binary flag is simpler and less complex then
> dealing with a binary flag. (i.e. what, when, how, why, who sets this flag?)
>
> Note: thoughts about the flag: What if a system by accident sends
> flip-flopping (set/unset/set/unset/etc) of this flag?
>
> Then other systems might misinterpret the results and generate
> inconsistent TLVs.  That would be bad.
>
> GV> correct, no good at all.
>
> What if an advertising system support multi-tlv for TLV ‘A’ but not
> for TLV ‘B’?
>
> We are not allowing that level of granularity.  A system that is going
> to support MP-TLVs should take care to operate correctly for ALL TLVs
> before advertising that it supports them.
>
> GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by
> the local system. This means that e.g. when new TLVs would be supported
> after a system upgrade, that the operator has to be aware and correct the
> flag during each single upgrade.
>
> GV> Unfortunately I remain to have troubles understanding the value
> "Multi-part TLV Capability’ flag brings to an ISIS network.
>   * Without flag it is indeed uncertain if area wide mp-tlv is
> supported (sub-optimal).
>   * but with catch all MP-TLV flag I am not sure we improve ISIS
> operation:
>   ** Who guarantees that the flag is set correctly on all systems at
> all times
>   ** Maybe all systems falls back to advertise single TLV because
> another (legacy?) system advertise a wrong flag  (sub-optimal)
>   ** Legacy system with MP-TLV support gets upgraded and now supports
> additional TLVs but not with MP-TLV...  ?manual intervention? 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Robert Raszuk]

All,

I am actually finding this capability useful. If for nothing else then to
help the operator to see what is going on in the area. On any node simple
show command will clearly show who is willing and capable to receive
MP-TLVs and who is not.

Analogy to including hostnames Tony brought here as an example is spot on
and along the same lines.

Of course how node uses that info could be discussed further. I would also
not object to put that capability into a separate document.

Thx,
R.





On Thu, Aug 25, 2022 at 6:06 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
> Hi Gunder, Tony, Les,
>
> I'm also not a fan of the Multi-Part TLV Capability flag. While the intent
> of the draft is to encourage multi-part TLV advertisement and usage, the
> addition of this flag and the requirement for advertisement will most
> likely have the opposite effect. Given that IS-IS implementations are
> already advertising multi-part TLVs but none are advertising the proposed
> capability flag, implementation of the draft as currently written would
> inhibit Multi-Part TLV usage and be a step backwards. Of course, we know
> implementations that are already advertising these multi-part TLVs will
> most likely ignore the recommendation and continue to advertise them even
> when not all IS-IS routers within the scope of the Multi-Part TLV advertise
> the capability.
>
> Rather, I propose that the draft eliminates the capability flag and
> introduces a recommended configuration parameter that would allow
> Multi-Part TLVs to be suppressed. The recommended default would be FALSE.
> This would provide an out if these Multi-Part TLVs did, in fact, have dire
> consequences.
>
> Thanks,
> Acee
>
> On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia -
> BE/Antwerp)"  gunter.van_de_ve...@nokia.com> wrote:
>
> Inline: GV>
>
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, August 24, 2022 5:26 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
> Hi Gunter,
>
> I am having troubles understanding the value of ‘The Multi-part TLV
> Capability’ flag.
> What would break if ‘Multi-part TLV Capability’ flag would not exist?
>
>
> A system that supported MP-TLVs would not be able to determine that
> there were other systems in the area that did not support MP-TLVs.  The
> system might then advertise MP-TLVs and they would be misinterpreted or
> cause system crashes in the systems that did not support them.
>
> GV> crashes? I really hope that is not happening.
> GV> When a legacy router receives MP-TLVs from another system and
> legacy router has no support for handling MP-TLV, then yes, things get
> misinterpreted. There is nothing wrong with that, is there? Do you have an
> example where things go wrong?
>
> If we want to introduce MP-TLVs, that change would warrant the
> existence of the flag.
>
> GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS
> behave better
>
> I dispute that a binary flag warrants the word ‘complexity’.
>
> GV>  living without binary flag is simpler and less complex then
> dealing with a binary flag. (i.e. what, when, how, why, who sets this flag?)
>
> Note: thoughts about the flag: What if a system by accident sends
> flip-flopping (set/unset/set/unset/etc) of this flag?
>
> Then other systems might misinterpret the results and generate
> inconsistent TLVs.  That would be bad.
>
> GV> correct, no good at all.
>
> What if an advertising system support multi-tlv for TLV ‘A’ but not
> for TLV ‘B’?
>
> We are not allowing that level of granularity.  A system that is going
> to support MP-TLVs should take care to operate correctly for ALL TLVs
> before advertising that it supports them.
>
> GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by
> the local system. This means that e.g. when new TLVs would be supported
> after a system upgrade, that the operator has to be aware and correct the
> flag during each single upgrade.
>
> GV> Unfortunately I remain to have troubles understanding the value
> "Multi-part TLV Capability’ flag brings to an ISIS network.
>   * Without flag it is indeed uncertain if area wide mp-tlv is
> supported (sub-optimal).
>   * but with catch all MP-TLV flag I am not sure we improve ISIS
> operation:
>   ** Who guarantees that the flag is set correctly on all systems at
> all times
>   ** Maybe all systems falls back to advertise single TLV because
> another (legacy?) system advertise a wrong flag  (sub-optimal)
>   ** Legacy system with MP-TLV support gets upgraded and now supports
> additional TLVs but not with MP-TLV...  ?manual intervention? (sub-optimal)
>   ** what, when, how, why, who sets the MP-TLV flag? What with
> flapping of MP-TLV flag (undefined)
>
> G/
>
> 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Acee Lindem (acee)]

I agree that retaining the option and using it for debugging would be a good 
thing. However, given that multi-part TLVs are already in use, the absence of 
the advertisement doesn’t necessarily mean that the IS-IS router doesn’t 
support multi-part TLVs. Rather, it presence would mean that beyond a shadow of 
a doubt, they are supported.

Similarly, for backward compatibility,  an IS-IS router would not be required 
to strictly enforce the requirement that all IS-IS routers within the scope of 
the Multi-Part TLV advertise the capability.

Thanks,
Acee

From: Lsr  on behalf of Robert Raszuk 
Date: Thursday, August 25, 2022 at 12:18 PM
To: "Acee Lindem (acee)" 
Cc: Gunter Van de Velde , Tony Li 
, lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

All,

I am actually finding this capability useful. If for nothing else then to help 
the operator to see what is going on in the area. On any node simple show 
command will clearly show who is willing and capable to receive MP-TLVs and who 
is not.

Analogy to including hostnames Tony brought here as an example is spot on and 
along the same lines.

Of course how node uses that info could be discussed further. I would also not 
object to put that capability into a separate document.

Thx,
R.





On Thu, Aug 25, 2022 at 6:06 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as WG member:

Hi Gunder, Tony, Les,

I'm also not a fan of the Multi-Part TLV Capability flag. While the intent of 
the draft is to encourage multi-part TLV advertisement and usage, the addition 
of this flag and the requirement for advertisement will most likely have the 
opposite effect. Given that IS-IS implementations are already advertising 
multi-part TLVs but none are advertising the proposed capability flag, 
implementation of the draft as currently written would inhibit Multi-Part TLV 
usage and be a step backwards. Of course, we know implementations that are 
already advertising these multi-part TLVs will most likely ignore the 
recommendation and continue to advertise them even when not all IS-IS routers 
within the scope of the Multi-Part TLV advertise the capability.

Rather, I propose that the draft eliminates the capability flag and introduces 
a recommended configuration parameter that would allow Multi-Part TLVs to be 
suppressed. The recommended default would be FALSE. This would provide an out 
if these Multi-Part TLVs did, in fact, have dire consequences.

Thanks,
Acee

On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - 
BE/Antwerp)" mailto:lsr-boun...@ietf.org> on behalf of 
gunter.van_de_ve...@nokia.com> wrote:

Inline: GV>

From: Tony Li mailto:tony1ath...@gmail.com>> On 
Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV 
Capability’ flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist?


A system that supported MP-TLVs would not be able to determine that there 
were other systems in the area that did not support MP-TLVs.  The system might 
then advertise MP-TLVs and they would be misinterpreted or cause system crashes 
in the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy 
router has no support for handling MP-TLV, then yes, things get misinterpreted. 
There is nothing wrong with that, is there? Do you have an example where things 
go wrong?

If we want to introduce MP-TLVs, that change would warrant the existence of 
the flag.

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS 
behave better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing 
with a binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends 
flip-flopping (set/unset/set/unset/etc) of this flag?

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct