Benjamin Schwartz <[email protected]> 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 other concern that I have with RISAV is that it seems unreasonable
mcr> that
mcr> an AS have only a single ACS. Maybe this can be accomplished via an
mcr> anycast situation,
> Yes, personally I imagine implementing the ACS as an anycast service.
I think that the system would be better if that was explicit.
>> I can imagine a situation where the ACS together, pick an appropriate
>> pair of ASBRs to form a tunnel between them.
>>
>> Should a global ISP should be hairpinning traffic across the Pacific
>> when it secures traffic between two AsiaPacific entities?
>>
> Obviously not, and RISAV intends to avoid that.
...
> I like the idea of a new WG, especially since IPSECME seems quite busy.
> However, I do think the various multi-SA/multi-sender drafts in IPSECME
> (esp. [1][2]) should be in the same WG as RISAV, as it depends heavily
> on that capability.
We have to get simultaneous IPsec, 6man and BGP review.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
