David,
On 2009-02-19 11:27, David W. Hankins wrote:
> First, thank you Brian for responding and thinking about this, I do
> appreciate it. My writing style is sometimes dry.
This is the IETF, isn't it? ;-) Dry is fine...
> On Thu, Feb 19, 2009 at 11:04:28AM +1300, Brian E Carpenter wrote:
>> Actually, wouldn't it allow a clever NAT to update session state
>> automatically?
>
> If you were to have two nodes sharing NAT mapping state, why would you
> prefer to wait for DHCP renewal timers rather than to have the
> surviving CGN simply take over routing for its peer's /128? This is
> the area of solutions I mean when I say I would expect 'tunnels' to
> be handled by routing equipment, and solved with classic routing
> solutions.
>
> Surely by the time you are coordinating such NAT tables, the idea of
> coordinating the use of /128s (fallbacks, anycasts) is trivial, and
> preferrable to placing complications on the softwire-client end?
I won't argue with you for the currently envisaged scenarios. I've
been looking at things with slightly different eyes while working
on draft-carpenter-renum-needs-work, because there seem to be quite
a lot of existing mechanisms that could be repurposed to support
dynamic renumbering, and there make-before-break has benefits.
Brian
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
