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

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Jul 2012 08:51:23 -0400

Behaviers, PCPers,

During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was 
filed regarding the PCP requirement. Details below.

I think this DISCUSS needs to be discussed. So please discuss.

Please reply to [email-masked].

Thanks,
Simon

-------- Message original --------
Sujet: Re: Martin Stiemerling's Discuss on 
draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
Date : Thu, 19 Jul 2012 10:46:42 +0200
De : Martin Stiemerling <[email-masked]>
Pour : Simon Perreault <[email-masked]>
Copie à : The IESG <[email-masked]>, <[email-masked]>, 
<[email-masked]>

Hi Simon, all,

On 07/17/2012 11:11 PM, Simon Perreault wrote:
> Le 2012-07-17 16:42, Martin Stiemerling a écrit :
>>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll
>>> fix the text in a later revision.
>>
>> Can we mandate a specific protocol to be used for this or can we only
>> mandate that such a type of protocol is being used? I don't see the IETF
>> in the position to mandate this type of protocol for CGNs.
>>
>> There are other protocols out there which might be suitable. Note that I
>> am co-author of some, but this isn't the reason for the question. I do
>> not get any reward if I promote these protocols.
>>
>> It is more:
>> do we need to constrain CGN deployments to a protocol (PCP) which is
>> developed right now, or are we open to existing or future protocols, or
>> whatever folks deploying this deem right?
>>
>> I would propose to change REQ-9 to :
>> REQ-9: A CGN MUST include a middlebox control protocol that allows
>> manipulation of CGN bindings with the following contstraints <list items
>> A and B>
>> REQ-9a: If PCP is used these contstraints MUST be applied in addition to
>> contraints A and B:
>> <list items C and D>
>
> That was discussed in IETF 81 (Québec). Here's the extract from the
> minutes:
>
>            Stuart Cheshire: ietf has one port forwarding protocol, which
>            is PCP, so we should require it by name

There are multiple middlebox control protocols published by the IETF
(standards track and experimental) and I have not seen any call for
consensus on what **the** IETF's middlebox control is, neither I have
seen any RFC that states this.

I do not see that an individual can declare IETF consensus based on his
own opinion.

>
>            Dave Thaler: I agree. PCP doc is in final stages.

Again, an opinion of an individual. Nothing wrong about it, but it does
not state IETF consensus.

>
> There was consensus from the WG. In consequence, the text was changed
> from this (-02):
>
>              A CGN SHOULD support a port forwarding protocol such as the
>              Port Control Protocol [I-D.ietf-pcp-base].
>
> to this (-03):
>
>             A CGN SHOULD include a Port Control Protocol server
>             [I-D.ietf-pcp-base].
>
> (That requirement later became a MUST, but that's orthogonal to what
> protocol we require.)

I do not see that the IETF can mandate what protocols are being used to
control a device. The market will decide!

For instance, the is no MUST required that routers implement BGP. It is
good to do this, but if one decides to go for IS-IS (or whatever) that
is just fine.

Another example, there is also no MUST requirement that routers, or
hosts in general, have to implement SNMP.

However, I can see the immediate need to mandate that a CGN SHOULD/MUST
support a middlebox control protocol that is able to install and
maintain NAT bindings.

   Martin

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Jul 2012 09:02:33 -0400

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.

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.

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Jul 2012 19:05:17 +0300

I agree with Martin's remarks.

On Jul 19, 2012, at 3:51 PM, Simon Perreault wrote:

> Behaviers, PCPers,
> 
> During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was filed regarding the PCP requirement. Details below.
> 
> Sujet: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT)
> Copie à : The IESG <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> Hi Simon, all,
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 19 Jul 2012 16:19:25 +0000

Humm...I'm not sure I agree.

"However, if a router does implement EGP it also MUST IMPLEMENT BGP."

http://www.ietf.org/rfc/rfc1812.txt

Or look at the requirements for IPv6 CEs or any other device that needs to
interoperate with others.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Jul 2012 14:35:17 -0400

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Jul 2012 16:16:31 -0400

>>>>> "David" == David Harrington <[email-masked]> 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.

---

From: David Harrington <[email-masked]>
Date: Thu, 19 Jul 2012 14:20:53 -0400

Some vendors might be implementing the (not yet IETF-approved) PCP
standard, and would prefer that solution.

>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.

>understand if the IESG wanted to ask behave to spend a little more time

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

David Harrington
[email-masked]
+1-603-828-1401