Warren Kumari <war...@kumari.net> writes:
On Wed, Aug 24 2022 at 8:35 PM, Christian Hopps <cho...@chopps.org>
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
