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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 19 July 2012 20:16 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80411E809B; Thu, 19 Jul 2012 13:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.857
X-Spam-Level:
X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxAaKkdCMFMK; Thu, 19 Jul 2012 13:16:07 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3172711E8099; Thu, 19 Jul 2012 13:16:06 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 69E72203BA; Thu, 19 Jul 2012 16:17:15 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B22541F0; Thu, 19 Jul 2012 16:16:31 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: David Harrington <ietfdbh@comcast.net>
References: <CC2DB8AA.23DF4%ietfdbh@comcast.net>
Date: Thu, 19 Jul 2012 16:16:31 -0400
In-Reply-To: <CC2DB8AA.23DF4%ietfdbh@comcast.net> (David Harrington's message of "Thu, 19 Jul 2012 14:20:53 -0400")
Message-ID: <tsl4np3h5gg.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: pcp@ietf.org, "behave@ietf.org" <behave@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [pcp] [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 20:16:08 -0000

>>>>> "David" == David Harrington <ietfdbh@comcast.net> writes:

    David> The IETF could mandate a specific protocol to try to ensure
    David> interoperability, but doing this takes the decision out of the
    David> responsibility of the deployer to choose the best solution for the
    David> deployment environment, and out of the responsibility of the vendor to
    David> best meet their customers' demands.


This doesn't make any sense to me at all.
It makes sense if   the vendor that the ISP is going to use (the CGN
vendor) is somehow related to the vendor that the customer is going to
use (the CPE vendor).

However, one of the explicitly stated assumptions in the behave-lsn
document is that is not the case.
The customer gets to choose a CPE vendor and the operator gets to choose
a CGN vendor.

The deployment environment here is the Internet.

In cases like this in the past we have chosen a technology.
I'm reasonably sure that host requirements mandate DNS as the name
service protocol. We don't want one isp to choose  some big LDAP
directory and one ISP  to choose DNS.
We want customers name resolution to continue to work (with the same CPE
they already have) as they move from one ISP to another.

The same arguments apply here .

Under the assumptions of this BCP, there is not a boundary between
deployment environments across which one deployment could use PCP and
another SNMP. (I am not aware of netconf schema that does anything
similar to PCP that has been standardized.)

Even obvious deployment environments like cable vs DSL don't make
sense. I can buy my own router and stick it behind either a cable modem
or a DSL router. People often do this. With some ISPs the configuration
gets a little tricky and you may introduce an extra level of
NAT. However, people deploy their own customer gateways on cable, DSL,
even in some cases mobile wireless.

BGP was held up as an example, namely that we don't mandate the
implementation of BGP.  Well, not all routers should implement BGP. My
little Linksys box has no need for it.  However, if we wrote
requirements for routers participating in the core routing
infrastructure--routers between large organizations and ISP--we'd almost
certainly mandate BGP.

Not all NATs need the same middlebox control protocol. However, this
document does not apply to all NATs. It applies to NATs that cross
organizational boundaries.  That's exactly the environment where saying
something like "this is an SNMP deployment," confuses me because I don't
think there will be uniform characterizations of the deployment.