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

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 >

Re: [IPsec] RISAV proposal at SECDISPATCH

2023-03-24 Thread gengnan
AS X validate incoming packets (src=P2, dst=P1) when AS Z also enables risav? 3. How do ACSes communicate with ASBRs? Best, Nan From: IPsec On Behalf Of Benjamin Schwartz Sent: Thursday, March 23, 2023 5:19 AM To: Michael Richardson Cc: secdispatch ; ipsec@ietf.org Subject: Re: [IPsec] RISAV

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

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

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

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

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

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

[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