Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

[Reinaldo Penno <[e-mail]>]

First of all you state that all NAT64 implementations will be the same
because the standard is new. Therefore  I did the following exercise:

I re-read a _single_ section of NAT64 (3.2.4.  ICMP Query Session Handling).
I found that developers have the following choices (and this does not go
into implementation details):

* Local Security Policy can drop ICMPv6 packets (yes/no)
* Local Security Policy can drop ICMPv6 packets configurable per
  interface/rule/etc (yes/no for each one)
* ICMPv6 lifetime can be configurable (yes/no)
* ICMPv6 lifetime can be configurable within a certain range (yes/no)
* ICMPv6 lifetime can be configurable with a granularity of ms/seconds/etc
  (yes/no)
* ICMPv4 message will be sent back to sender (yes/no/configurable)
* ICMPv4 message will be sent back to sender per configuration
  interface/nat rule/etc (yes/no each one)
* ICMPv4 message will be sent back to sender in case of filtering
  (yes/no/configurable)
* ICMPv4 message will be sent back to sender per configuration
  (interface/rule/etc)
* ICMPv4 lifetime can be configurable (yes/no)
* ICMPv4 lifetime can be configurable within a certain range (yes/no)
* ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc
  (yes/no)
 
And do not even get me started in generic address-filtering behavior which
is much more complex and have more implementation choices.

And this the way things are because different providers have different
networks and provider service to customer with different needs.

Second, you indicate that operational complexity is something on the side.

Providers are interested in Service Continuity as a solution. Operational
complexity cannot be dismissed off hand with 'This is an operational issue'.
Several people made this point clear in the list.

But, let's take this further:

Can you elaborate on which tests need to be done in order to guarantee that
this scenario will work between two different vendors?

Of course after the provider go through all the tests for this single and
only scenario, if NAT64-A or NAT64-B needs to be upgraded, it is not
guarantee that things will work again. Software from different vendors
evolve differently, are EOLed differently, change behavior differently.

Finally, If you pin down all specific behavior you need within all possible
permutations of different vendors, weigh the operational cost of a
multi-dimensional testing to find two boxes that can provide the High
Availability with the NAT behavior you need, I think you will find out that
NAT64-A and NAT64-B are made by the same vendor.


Thanks,


On 12/3/09 4:15 AM, "Simon Perreault" <[e-mail]> wrote:

> On 12/02/2009 10:14 PM, Reinaldo Penno wrote:
>> Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is
>> processing packets for 3 NAT sessions and as master have synched these 3 NAT
>> sessions to NAT-B.
>> 
>> If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B will
>> be able to handle these sessions in terms of packets per second?
> 
> Assuming s/NAT/NAT64/g...
> 
> This is an operational issue. You just ensure that this will work when
> you buy and deploy A and B. Check spec sheets, chat with vendors,
> perform tests, etc.
> 
> What's your point?
> 
> Simon