Le 2012-07-19 14:20, David Harrington a écrit :
The IETF could mandate a specific protocol to try to ensure
interoperability, but doing this takes the decision out of the
responsibility of the deployer to choose the best solution for the
deployment environment, and out of the responsibility of the vendor to
best meet their customers' demands.
Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB
might best meet their needs.
Some vendors might support a Netconf environment and desire a
Netconf-based configuration solution.
Some vendors already use AAA widely to control their environment, and
Diameter NAT control might be preferable.
Careful here. The above protocols are not used between the CPE and the
CGN. The requirement for PCP (or PCP-like) is justified by the need for
subscribers to be able to control the CGN to some extent.
Note also that any of those protocols could also be supported in
addition to PCP, up to the implementer and operator.
Of course, if CGN is only an ipv4 exit strategy, as is asserted,
Not as asserted by the draft, I hope. We have tried making clear that
CGN as defined in this document really stands for "multi-user NAT" and
that there are use cases that have nothing to do with IPv4 sunset (e.g.
the NAT function in a wifi hotspot is a CGN).
The CGN logical function may or may not be used as part of an IPv4
sunset scenario. As such, it is is absolutely part of behave's core
expertise. Sunset4 could have things to say about how CGN gets applied
to IPv4 sunset, but how CGN behaves is up to behave.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca