Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Hi, On 2022-8-25, at 12:49, Christian Hopps wrote: > One example of a simple slow-trip circuit breaker (CB) an > implementation may provide would utilize 2 values, the amount > of persistent loss rate required to trip the CB and the > required length of time this persistent loss rate must be seen > to trip the CB. These 2 value are required configuration from > the user. When the CB is tripped the tunnel traffic is disabled, > and an appropriate log message or other management type > alarm is triggered indicating operate intervention is required. Thanks, this works for me. Lars signature.asc Description: Message signed with OpenPGP ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Lars Eggert writes: Sorry for the top post. The text below is not sufficient. 8084 gives guidance on how to specify a CB , but doesn’t itself specify a solution that can just be pointed to. This document needs to define how, based on the guidance in 8084, a CB should be implemented for this specific protocol. Hi Lars, That was not required of pseudowires, I'm wondering why we are different here. We do in fact indicate that congestion reports should be enabled when implementing a circuit breaker to provide the sender with the RFC8084 required information. How sophisticated a vendor makes their circuit breakers (e.g., the types of controls they offer to the user etc), is a method of market differentiation. Normally IETF does not limit this unless it is required for protocol interoperability. If you're requiring that we give an example of a simple CB implementation for vendors incapable of figuring this out (I'm not sure how they managed to implement the rest of the protocol w/o being able to do this but anyway..)? I can add the following text if it will clear the DISCUSS. One example of a simple slow-trip circuit breaker (CB) an implementation may provide would utilize 2 values, the amount of persistent loss rate required to trip the CB and the required length of time this persistent loss rate must be seen to trip the CB. These 2 value are required configuration from the user. When the CB is tripped the tunnel traffic is disabled, and an appropriate log message or other management type alarm is triggered indicating operate intervention is required. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Sorry for the top post. The text below is not sufficient. 8084 gives guidance on how to specify a CB , but doesn’t itself specify a solution that can just be pointed to. This document needs to define how, based on the guidance in 8084, a CB should be implemented for this specific protocol. -- Sent from a mobile device; please excuse typos. > On Aug 25, 2022, at 03:28, Christian Hopps wrote: > > 2.4.2.1. Circuit Breakers > > In additional to congestion control, implementations that support > non-congestion control mode SHOULD implement circuit breakers > [RFC8084] as a recovery method of last resort. When circuit breakers > are enabled an implementation SHOULD also enable congestion control > reports so that circuit breakers have information to act on. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Warren Kumari writes: On Wed, Aug 24 2022 at 8:35 PM, Christian Hopps wrote: If you own/control/have the rights to the entire network, then you have the same over all the paths through the network. There are organizations that wish to deploy IPTFS protected tunnels at their fixed rate w/o congestion control, over said networks. And they should be able to. I'm not trying to stop you / them, but I *am* trying to minimize the chances of foot-shooting. Having text which helps operators deploy this in a manner that doesn't cause issues for their network, especially during events like described above, means that they are more likely to actually deploy and use it. I'm sure that there are organizations who do want to deploy this - it has some very cool properties - but if they do, and it bites them because there was some operational advice/considerations that were left out, they will turn it off... Indeed. And so in addition to the existing warnings/advice given in the non-congestion control mode section, which states the user should only run this over their own networks in this mode, and additionally they need to guarantee the bandwidth for the tunnel, we have improved and added another reference in the circuit breakers section as well to the PW congestion considerations document that Lars alluded to. 2.4.2.1. Circuit Breakers In additional to congestion control, implementations that support non-congestion control mode SHOULD implement circuit breakers [RFC8084] as a recovery method of last resort. When circuit breakers are enabled an implementation SHOULD also enable congestion control reports so that circuit breakers have information to act on. The pseudowire congestion considerations [RFC7893] are equally applicable to the mechanisms defined in this document, notably the text on inellastic traffic. Is this now sufficient? Thanks, Chris. W Thanks, Chris. > > > > > "full admin control" is a necessary prerequisite to mitigate/ manage issues, but not a solution in itself. > This CBR ESP tunnel is basically identical to a CBR pseudowire. There was quite a bit of work/discussion between PWE3 and various transport groups in the past that resulted in a set of guidance on how such pseudowires are safe to deploy. This guidance needs to be adopted here as well (or we'll need a much longer discussion on what alternative guidance could look like and why.) > > > > > I'll happily admit that I haven't read that / those discussions, but I'm glad that it sounds like there is existing work that can be cribbed from… > W > > > Thanks, Lars > signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
On Wed, Aug 24 2022 at 8:35 PM, Christian Hopps wrote: > Warren Kumari writes: > > On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: > > > > > > > Hi, > > > > > On 2022-8-24, at 2:08, Christian Hopps wrote: > > > > > How about we add the text "This MUST NOT be used when full > admin control over the network cannot be assured."? > > > > > > > > > I don't really understand what "full admin control over the network" > really means… well, I do know what that means, but I don't really know as > an operator what the implication are. If I have a site with a 10GE primary > link, and a 1GE for the backup, I have "full admin control", but I still > presumably shouldn't configure this to use 2Gbps, or I need to ensure that > I have firewall filters to block this traffic if the primary link goes > down… > > It means you own, have rights to, and/or control the entire network the > tunnel will operate over. > > I guess that I don't really understand how this would be expected to be > deployed in practice and what sort of expected CBR is expected. Any > solution which generates a constant rate of traffic and doesn't understand > congestion certainly seems like it is likely to cause issues unless is can > be constrained to a single path and / or be known to be the only traffic > source on that path (like a bump-in-the-wire solution). > > If you own/control/have the rights to the entire network, then you have > the same over all the paths through the network. There are organizations > that wish to deploy IPTFS protected tunnels at their fixed rate w/o > congestion control, over said networks. And they should be able to. > I'm not trying to stop you / them, but I *am* trying to minimize the chances of foot-shooting. Having text which helps operators deploy this in a manner that doesn't cause issues for their network, especially during events like described above, means that they are more likely to actually deploy and use it. I'm sure that there are organizations who do want to deploy this - it has some very cool properties - but if they do, and it bites them because there was some operational advice/considerations that were left out, they will turn it off... W Thanks, > Chris. > > > > > > > > > > > > > "full admin control" is a necessary prerequisite to mitigate/ > manage issues, but not a solution in itself. > > > > > This CBR ESP tunnel is basically identical to a CBR pseudowire. > There was quite a bit of work/discussion between PWE3 and various > transport groups in the past that resulted in a set of guidance > on how such pseudowires are safe to deploy. This guidance needs > to be adopted here as well (or we'll need a much longer > discussion on what alternative guidance could look like and why.) > > > > > > > > > > > > > I'll happily admit that I haven't read that / those discussions, but I'm > glad that it sounds like there is existing work that can be cribbed from… > > > > > W > > > > > > > > > Thanks, > Lars > > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Hi Warren, Warren Kumari writes: On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: This CBR ESP tunnel is basically identical to a CBR pseudowire. There was quite a bit of work/discussion between PWE3 and various transport groups in the past that resulted in a set of guidance on how such pseudowires are safe to deploy. This guidance needs to be adopted here as well (or we'll need a much longer discussion on what alternative guidance could look like and why.) I'll happily admit that I haven't read that / those discussions, but I'm glad that it sounds like there is existing work that can be cribbed from… Indeed, and we have in fact added a reference to RFC7893 to the document in response to resolving this DISCUSS. :) Thanks, Chris. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Warren Kumari writes: On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: Hi, On 2022-8-24, at 2:08, Christian Hopps wrote: How about we add the text "This MUST NOT be used when full admin control over the network cannot be assured."? I don't really understand what "full admin control over the network" really means… well, I do know what that means, but I don't really know as an operator what the implication are. If I have a site with a 10GE primary link, and a 1GE for the backup, I have "full admin control", but I still presumably shouldn't configure this to use 2Gbps, or I need to ensure that I have firewall filters to block this traffic if the primary link goes down… It means you own, have rights to, and/or control the entire network the tunnel will operate over. I guess that I don't really understand how this would be expected to be deployed in practice and what sort of expected CBR is expected. Any solution which generates a constant rate of traffic and doesn't understand congestion certainly seems like it is likely to cause issues unless is can be constrained to a single path and / or be known to be the only traffic source on that path (like a bump-in-the-wire solution). If you own/control/have the rights to the entire network, then you have the same over all the paths through the network. There are organizations that wish to deploy IPTFS protected tunnels at their fixed rate w/o congestion control, over said networks. And they should be able to. Thanks, Chris. "full admin control" is a necessary prerequisite to mitigate/ manage issues, but not a solution in itself. This CBR ESP tunnel is basically identical to a CBR pseudowire. There was quite a bit of work/discussion between PWE3 and various transport groups in the past that resulted in a set of guidance on how such pseudowires are safe to deploy. This guidance needs to be adopted here as well (or we'll need a much longer discussion on what alternative guidance could look like and why.) I'll happily admit that I haven't read that / those discussions, but I'm glad that it sounds like there is existing work that can be cribbed from… W Thanks, Lars signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
On Wed, Aug 24, 2022 at 5:33 AM, Lars Eggert wrote: > Hi, > > On 2022-8-24, at 2:08, Christian Hopps wrote: > > How about we add the text "This MUST NOT be used when full admin control > over the network cannot be assured."? > > I don't really understand what "full admin control over the network" really means… well, I do know what that means, but I don't really know as an operator what the implication are. If I have a site with a 10GE primary link, and a 1GE for the backup, I have "full admin control", but I still presumably shouldn't configure this to use 2Gbps, or I need to ensure that I have firewall filters to block this traffic if the primary link goes down… I guess that I don't really understand how this would be expected to be deployed in practice and what sort of expected CBR is expected. Any solution which generates a constant rate of traffic and doesn't understand congestion certainly seems like it is likely to cause issues unless is can be constrained to a single path and / or be known to be the only traffic source on that path (like a bump-in-the-wire solution). > "full admin control" is a necessary prerequisite to mitigate/manage > issues, but not a solution in itself. > > This CBR ESP tunnel is basically identical to a CBR pseudowire. There was > quite a bit of work/discussion between PWE3 and various transport groups in > the past that resulted in a set of guidance on how such pseudowires are > safe to deploy. This guidance needs to be adopted here as well (or we'll > need a much longer discussion on what alternative guidance could look like > and why.) > > > I'll happily admit that I haven't read that / those discussions, but I'm glad that it sounds like there is existing work that can be cribbed from… W Thanks, > Lars > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
> On Aug 24, 2022, at 05:33, Lars Eggert wrote: > > Hi, > > On 2022-8-24, at 2:08, Christian Hopps wrote: >> How about we add the text "This MUST NOT be used when full admin control >> over the network cannot be assured."? > > "full admin control" is a necessary prerequisite to mitigate/manage issues, > but not a solution in itself. > > This CBR ESP tunnel is basically identical to a CBR pseudowire. There was > quite a bit of work/discussion between PWE3 and various transport groups in > the past that resulted in a set of guidance on how such pseudowires are safe > to deploy. This guidance needs to be adopted here as well (or we'll need a > much longer discussion on what alternative guidance could look like and why.) We will add a reference to the pseudowire congestion considerations RFC 7893 in the section where we discuss circuit breakers. Thanks, Chris. > > Thanks, > Lars > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Hi, On 2022-8-24, at 2:08, Christian Hopps wrote: > How about we add the text "This MUST NOT be used when full admin control over > the network cannot be assured."? "full admin control" is a necessary prerequisite to mitigate/manage issues, but not a solution in itself. This CBR ESP tunnel is basically identical to a CBR pseudowire. There was quite a bit of work/discussion between PWE3 and various transport groups in the past that resulted in a set of guidance on how such pseudowires are safe to deploy. This guidance needs to be adopted here as well (or we'll need a much longer discussion on what alternative guidance could look like and why.) Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Warren Kumari via Datatracker writes: Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Discuss -- DISCUSS: -- How about we add the text "This MUST NOT be used when full admin control over the network cannot be assured."? Thanks, Chris. I supporting Lars' DISCUSS points, especially that around Section 2.4.1, paragraph 3: The packet send rate is constant and is not automatically adjusted regardless of any network congestion (e.g., packet loss). For similar reasons as given in [RFC7510] the non-congestion- controlled mode should only be used where the user has full administrative control over the path the tunnel will take. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married... It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences. -- COMMENT: -- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- DISCUSS: -- I supporting Lars' DISCUSS points, especially that around Section 2.4.1, paragraph 3: The packet send rate is constant and is not automatically adjusted regardless of any network congestion (e.g., packet loss). For similar reasons as given in [RFC7510] the non-congestion- controlled mode should only be used where the user has full administrative control over the path the tunnel will take. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married... It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences. -- COMMENT: -- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
