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

[David Harrington <[e-mail]>]

On 7/19/12 9:02 AM, "Sam Hartman" <[e-mail]> wrote:

>I think that behave-lsn-requirements is far more useful if it names a
>specific protocol by name.  By endorcing one of our middlebox protocols,
>we encourage interoperability.  If we don't pick a protocol by name, we
>don't really promote interoperability. It's not useful if your CGN does
>midcom and my client does PCP and I'm your customer.  The assumption
>behind LSN-requirements is that the CGN and the CPE are not
>controlled/purchased/whatever by the same entity.  So, mandating a
>specific protocol seems desirable.

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.
Some vendors might be implementing the (not yet IETF-approved) PCP
standard, and would prefer that solution.

>
>I think that the behave WG is the right place to make that decision.
>The IETF as a whole should be able to second guess behave, but we should
>need a fairly high bar  for  doing so.

I think that **within IETF**, behave wg might have the right expertise to
make this decision (technical comparison of middlebox protocols by
protocol designers). Of course, no current WG has much input from
proponents of the original MIDCOM WG strategy, and most Diameter
proponents are not very active in behave wg. And behave DOES have an
overlap between the PCP developers and behave solutions. So behave WG
might be rather biased toward a specific solution (not that the bias is
necessarily bad, but the bias should be recognized).

Of course, if CGN is only an ipv4 exit strategy, as is asserted, then
sunset4 would seem the appropriate choice, so we have one consistent ipv4
exit strategy.
We already recognize that different wgs are developing ipv4 exit
strategies that conflict; that's why a sunset4 wg has been approved.
And if CGN **is** only for ipv4-sunsetting, a "this IETF recommendation
becomes obsolete on such-and-such a date" might be appropriate for
lsn-requirements.
The right expertise might be in the sunset4 wg, which might have increased
operator input about a complete ipv4/ipv6 transition deployment strategy
rather than middlebox protocol design comparisons by middlebox protocol
designers.

While I would love to see consensus for a good interoperable solution, and
would support ***A*** standard that says "to be compliant to THIS
specification, use THIS middlebox proposal", I hesitate to say "this is
the ONLY middlebox standard that is recommended or usable within IETF
standards" - especially if that only recommended part has little or no
actual field experience to back up the RECOMMENDED, and little or no
documentation has been done of the suitability/useability in various
environments of the existing IETF standards that would become NOT
RECOMMENDED.

I think the right place to make the decision about which midcom solution
should be used in a particular environment is in the market.
My cable provider lets me purchase/control my cable router (to a degree),
but only certain routers are supported.
I can choose which cable router offers the additional
functionality/control I want for my environment.
My provider has input to the decision, and so do I (to a limited extent).
Of course, to a limited extent, I can also choose a different provider or
get less support from my provider.


>
>The claim that PCP is the IETF's only protocol in this space does seem a
>little bit on the wishful thinking side of things. So, I could
>understand if the IESG wanted to ask behave to spend a little more time
>on the question.

+1 (or ask sunset4 to spend a little more time on the question).


David Harrington
[e-mail]
[phone]