Ben Schwartz wrote:
>> Ben Schwartz wrote: > We've just
>> put out an extensively revised version of our RISAV proposal > (the I
>> stands for IPsec). We'd like to start getting feedback from the >
>> IPsec experts. We're also hoping to present this idea and solicit >
>> fe
On Oct 21, 2022, at 23:50, Erik Kline wrote:
>
>
> You could also just say that ASBRs are presumed to be communicating within a
> well-managed environment, are often zero or one hops away from one another,
> and that this environment MUST accommodate the larger MTU for tunnel-mode
> IPsec en
On Sun, Oct 23, 2022 at 9:37 AM Paul Wouters wrote:
> On Oct 21, 2022, at 23:50, Erik Kline wrote:
> >
> >
> > You could also just say that ASBRs are presumed to be communicating
> within a well-managed environment, are often zero or one hops away from one
> another, and that this environment
On Fri, Oct 21, 2022 at 11:50 PM Erik Kline wrote:
> I suppose you could try to add a "we're exempt from 8200" paragraph and
> see what happens.
>
> You could also just say that ASBRs are presumed to be communicating within
> a well-managed environment, are often zero or one hops away from one
>
On Sun, Oct 23, 2022 at 9:08 AM Michael Richardson
wrote:
>
> Ben Schwartz wrote:
>
> > The real motivation to support AH in this draft comes down to MTU
> > overhead. Going from 24 bytes of MTU loss to 73 bytes seems
> > potentially significant, especially because:
>
> Where
On Sun, 23 Oct 2022, Erik Kline wrote:
> You could also just say that ASBRs are presumed to be communicating
within a well-managed environment,
are often zero or one hops away from one another, and that this
environment MUST accommodate the larger
MTU for tunnel-mode IPsec e
Paul Wouters wrote:
>> You could also just say that ASBRs are presumed to be communicating
>> within a well-managed environment, are often zero or one hops away from
>> one another, and that this environment MUST accommodate the larger MTU
>> for tunnel-mode IPsec encapsulation.
Ben Schwartz wrote:
>> Ben Schwartz wrote:
>>
>
>> > The real motivation to support AH in this draft comes down to MTU
>> > overhead. Going from 24 bytes of MTU loss to 73 bytes seems
>> > potentially significant, especially because:
>>
>> Where will you pu
