Re: [pcp] [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)

[Simon Perreault <[e-mail]>]

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