Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-24 Thread Michael Richardson
Benjamin Schwartz wrote: >> 3. How do ACSes communicate with ASBRs? > In my view, this is an "implementation detail" within a single AS, and is > out of scope for the draft. Personally, I imagine the ACS being an anycast > service implemented across all the ASBRs, using a distr

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-24 Thread Benjamin Schwartz
On Fri, Mar 24, 2023 at 3:11 AM gengnan wrote: > Hi Ben, > > > > In Tunnel Mode, if the source and destination addresses are replaced by > contact IPs, there will be one (or several) huge aggregated “flow” between > the two ASes. Does this pose a challenge to intermediate ASes that conduct > Traf

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-24 Thread gengnan
proposal at SECDISPATCH On Wed, Mar 15, 2023 at 11:09 AM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: Benjamin Schwartz mailto:i...@bemasc.net>> wrote: >> Benjamin Schwartz mailto:i...@bemasc.net>> wrote: > In Transport Mode, the >> tho

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-22 Thread Benjamin Schwartz
On Wed, Mar 15, 2023 at 11:09 AM Michael Richardson wrote: > > Benjamin Schwartz wrote: > >> Benjamin Schwartz wrote: > In Transport Mode, the > >> thought is mainly to _avoid_ traffic > engineering, and instead be > >> able to deploy RISAV with confidence that > your existing TE wi

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-15 Thread Michael Richardson
Benjamin Schwartz wrote: >> Benjamin Schwartz wrote: > In Transport Mode, the >> thought is mainly to _avoid_ traffic > engineering, and instead be >> able to deploy RISAV with confidence that > your existing TE will not >> be altered. >> >> I thought you replaced the des

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-15 Thread Benjamin Schwartz
On Wed, Mar 15, 2023 at 5:55 AM Michael Richardson wrote: > > Benjamin Schwartz wrote: > > In Transport Mode, the thought is mainly to _avoid_ traffic > > engineering, and instead be able to deploy RISAV with confidence that > > your existing TE will not be altered. > > I thought you

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-15 Thread Michael Richardson
Benjamin Schwartz wrote: > In Transport Mode, the thought is mainly to _avoid_ traffic > engineering, and instead be able to deploy RISAV with confidence that > your existing TE will not be altered. I thought you replaced the destination address with that of the ASBR? mcr> The o

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-14 Thread Benjamin Schwartz
On Tue, Mar 14, 2023 at 11:39 AM Michael Richardson wrote: > > TL;DR> Important work needing New WG in Routing Area. > > Hi, I thought I had read previous versions of RISAV... maybe under a > different draft name. Yes, it was previously draft-xu-risav. (The replacement is marked in the Datatra

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-14 Thread Paul Wouters
On Tue, 14 Mar 2023, Michael Richardson wrote: [speaking as individual] AH has essentially no deployment at this point, and so this is rather a good plan. We have been trying to kill it in favour of ESP-NULL, so I'm not sure I would want to encourage new deployment of it at this point. I thi

[IPsec] RISAV proposal at SECDISPATCH

2023-03-14 Thread Michael Richardson
TL;DR> Important work needing New WG in Routing Area. Hi, I thought I had read previous versions of RISAV... maybe under a different draft name. I find this version much better than I saw before. I have some specific technical comments about how to make this work simpler, but that's not a topic