Subject: [pcp] WG last call on draft-ietf-pcp-base-16.txt

From: RJ Atkinson <[email-masked]>
Date: Tue, 25 Oct 2011 10:24:03 -0400

> The PCP wg chairs would like to issue a one week wg last call
> on draft-ietf-pcp-base-16.
> 
> Last call ends Friday October 28th at 5pm EST.
> 
> Alain & Dave

(I apologise for the delayed reaction to the WG Last Call.
I only have intermittent network access at present.)

I object to this document moving forward on grounds that 
while this WG's primary objective is to standardise 
NAT-PMP/uPnP, an important commonly deployed operational 
capability of NAT-PMP is being omitted from this document.

There is significant operational experience with the 
"Rapid Recovery" capability of NAT-PMP.  It works well 
in the field.  Text exists in draft-cheshire-pcp-recovery-01, 
which is remarkably brief for an I-D, so there is no
work required to create text.

When this was discussed in early April this year on the 
IETF PCP mailing list, there was a single non-specific
and not-obviously-technical concern expressed by Rainaldo 
Penno on 1st April 2011.

That concern was addressed and seemed fully resolved by
Stuart Cheshire's clarification also on the IETF PCP
mailing list (posted the very next day).

Rainaldo did not follow up with any disagreement or concern
to Start's note of 2nd April, so he appears to be happy.  

No one else has expressed any concern about the Rapid
Recovery capability to the IETF PCP list.  

BOTTOM LINE:

I've reviewed the IETF PCP list archives and can't find 
any evidence of an unresolved concern about this feature.

So a reasonable member of this WG has no reason to believe 
the Rapid Recovery feature is controversial in any way, 
has any unresolved technical concern, and would not be 
included as part of the base specification (or at minimum 
placed into WG Last Call at the same time as the PCP base 
specification so they could proceed together).

PROPOSED RESOLUTION:

I see 2 different ways that my objection can be resolved.
Either one is fine with me.  Each seems quite simple.

A) IETF PCP WG Chairs place draft-cheshire-pcp-recovery-02 into
   WG Last Call immediately for publication on the IETF standards 
   track, with the document to be marked as an "Update" to the 
   draft-ietf-pcp-base-16.txt document.

or

B) IETF PCP WG Chairs suspend the current WG Last Call, 
   fold the text from draft-cheshire-pcp-recovery-02 into 
   a new version of the draft-ietf-pcp-base-* document, 
   and restart the WG Last Call on that revised version.

Yours, 

Ran Atkinson

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 25 Oct 2011 15:47:15 -0400

Hello RJ,

I did not follow up due to the fact that draft-cheshire-pcp-recovery-01
views things from a CPE/home perspective where multicast is pervasive. As
you point out, it is trying to recreate NAT-PMP's functionality.

My objection to draft-cheshire-pcp-recovery-01 is that relying on multicast
in service provider networks is not practical - although fine for home
networks.

Thanks,

Reinaldo

On 10/25/11 7:24 AM, "RJ Atkinson" <[email-masked]> wrote:

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Paul Selkirk <[email-masked]>
Date: Wed, 26 Oct 2011 04:44:22 +0000

So what you're objecting to is that draft-cheshire-pcp-recovery is not
part of the base PCP spec.

It's an optimization. PCP will work without it. PCP will work better
with it, in certain deployment scenarios (i.e. where IPv4 multicast
infrastructure is present, and the NAT is restarting often enough to be
an operational consideration).

OTOH, a) if we define it for IPv4 multicast, someone will surely and
immediately request it for IPv6 multicast; and b) the deployment
scenarios that PCP is looking at are CGN (DS-Lite, NAT444, or NAT64),
where NAT restarts should be much less frequent than in the home.

Also, c) we're under significant pressure from the v6ops WG to publish
the PCP base spec, because rfc6204bis supposedly depends on it.

That said, I would like to hear more about why you consider this such an
integral part of the protocol that we cannot publish the base spec
without it.

				paul

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 27 Oct 2011 06:11:39 -0400

On 25  Oct 2011, at 15:47 , Reinaldo Penno wrote:
> views things from a CPE/home perspective where multicast is pervasive.
> As you point out, it is trying to recreate NAT-PMP's functionality.

The Rapid Recovery capability is important to a large number 
of service providers and also to a large number of end sites
(academic, enterprise, residential, & other).  

For example, in most cases, the SP's own customers won't be satisfied 
if/when the PCP-capable device develops a fault and it takes a 
long time to recover.  Rapid Recovery is actually quite important 
for most service providers.

> My objection to draft-cheshire-pcp-recovery-01 is that relying
> on multicast in service provider networks is not practical

That claim is provably false as written.  You generalise 
to all service provider deployments, when in fact we all
know that most (possibly all, as you haven't provided any
specific counter-examples yet) SP deployments don't and won't
have any issues with this use of link-local multicasting.

I don't think we've met, but I have extensive Network Engineering 
experience with a multi-continent ISP, specifically including 
access engineering.  So I've got first-hand understanding of the 
SP environment, including a current client that operates a large
SP network on all continents and has a mixture of equipment
(including some from JNPR).  For many many SP deployments, 
I believe for the majority of service providers where PCP is likely 
to be applicable, multicast is available on the client-facing 
interfaces and the approach defined in Stuart Cheshire's I-D 
works fine.

* If you have some other approach to solve the same operational issue,
  please speak up.  I'm open-minded, but the time to put that on the table 
  was really last April.

* Alternately, if you were worried about some specific use case or
  specific narrow deployment model, you could propose some specific
  text to clarify the Rapid Recovery I-D's applicability.  Again,
  this really ought to have been done last April, but better late
  than never.

Yours,

Ran Atkinson

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 27 Oct 2011 06:39:42 -0400

> part of the base PCP spec.

That is not precisely correct; instead I object the absence of some 
reasonable approach to Rapid Recovery being standardised/specified
at the same time as the base specification.

draft-cheshire-pcp-recovery happens to be the only proposal on the 
table for Rapid Recovery that I'm aware of.  There is operational
experience indicating it works well -- and that its presence is
operationally important in real-world deployments.  If someone has
a different approach to propose, ideally one that also has operational
experience supporting that approach, there was ample time to present 
that during the past year -- and such an alternate proposal really
ought to have been offered in April when this topic arose on the 
WG mailing list.  Still, better to propose something late than never.

My original note outlined two different possible approaches 
to resolving my objection.  If someone wants to propose an 
alternative resolution -- one that will also specify a Rapid Recovery 
capability at the same time as the base specification, then I'm all ears.

> an operational consideration).

The above is one view.  

My own view, based on operational experience with uPnP and NAT-PMP is that 
PCP without Rapid Recovery will NOT work sufficiently well to be viable 
in real world deployments (this includes, but is not limited to, SP deployments).

> OTOH, a) if we define it for IPv4 multicast, someone will surely
> and immediately request it for IPv6 multicast;

If true, that's a trivial edit that could be made within a day.  
The IPv6 all-nodes link-local multicast address was defined 
over a decade ago and is widely supported in environments 
where native IPv6 is deployed.

> and b) the deployment scenarios that PCP is looking at are CGN
> (DS-Lite, NAT444, or NAT64), 

That very narrow reading of which deployment scenarios are within scope
is NOT consistent with the WG Charter, which is posted online here:
	<http://www.ietf.org/dyn/wg/charter/pcp-charter>

The charter is NOT limited to CGN cases, but instead is very broadly
written to include ALL use cases involving either NAT, Firewall, or both.

In any case, many existing CGN deployments and also many other
NAT/firewall deployments support the IP multicast approach defined 
in the current Rapid Recovery draft -- and those deployments are 
a very large part of why this capability is important.  Many SP customers 
need the rapid recovery property, which in turn means that many SPs
want to provide the rapid recovery property.

If one wants to edit the current Rapid Recovery I-D to clarify
some specific types of deployments where it is not applicable,
that also would appear to be a trivially simple edit.  Maybe one
could propose some suitable text for that, if that is one's
concern.

> where NAT restarts should be much less frequent than in the home.

Operational experience thus far indicates that NAT restarts are
common with CGN devices.

> the PCP base spec, because rfc6204bis supposedly depends on it.

Right, and the devices implementing that specification are among
those where this Rapid Recovery capability is both operationally 
critical and also where the approach in the current Rapid Recovery 
I-D is clearly supportable -- which means this capability needs 
to be specified in an RFC right now, not later on.

> integral part of the protocol that we cannot publish the base spec

As described above, operational experience from uPnP and NAT-PMP 
is that the "slow recovery" property of the current specification
will make the PCP protocol difficult or impossible to use in many
real-world deployments that are within the scope of this WG's
charter.

Yours,

Ran Atkinson

NB:  I have intermittent network access, until ~ 1st November,
so please accept my apology that I can't respond in as timely
a manner as I might prefer.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 27 Oct 2011 15:05:48 -0400

Hello RJ,

Thanks for the reply. I included comments inline.

> for most service providers.

Certainly. Can you clarify rapid vs. long? 1sec/1min/5min/30min?

Also, I would like to understand in your opinion if recovery times should be
the same across all end sites you mention. Should, say, residential
customers expect recovery in the same time as enterprise customers?

> have any issues with this use of link-local multicasting.

Well, multicast recovery is applicable if several conditions are met:

1 - PCP Client, Server and NAT are in the same domain.
2 - Multicast is enabled on both devices
3 - SP prefers a fully distributed deployment - which has capex/opex
    implications.
4 - Finally, PCP Server (which sends the multicast packet), NAT (controlled
    device) and BNG/GGSN (which knows the interface to send multicast
    packet) should ideally be the same device which might be the case or
    not.

>   please speak up.  I'm open-minded, but the time to put that on the table

I'm assuming you are asking the question assuming multicast is not
available. When multicast is not available one approach that comes to mind
is use shorter lifetimes. If an enterprise has hundreds of mappings it can
use a shorter lifetime for only a small % of mappings. That has the same
value of a keep-alive.

>   this really ought to have been done last April, but better late

See above. In my opinion it is the other way around. Meaning, the general
case is when PCP Server and Client can be any number of layer-3 hops away
and all you need is IP reachability. The narrow, or specific case, is when
all the other conditions are met and you can use multicast.

My original suggestion is the same: introduce an applicability section in
the draft.

---

From: james woodyatt <[email-masked]>
Date: Thu, 27 Oct 2011 13:57:00 -0700

everyone--

My apologies to working group for failing to notice this until Mr. Atkinson brought it to my attention.

On Oct 25, 2011, at 7:24 AM, RJ Atkinson wrote:
> 
> [...] an important commonly deployed operational 
> in the field.

I am the original author of the NAT-PMP service in Apple's implementations, i.e. AirPort Base Station, Time Capsule and the Mobile Internet Sharing operating mode of iOS on the iPhone.  I have significant experience with this.

I have to say I'm surprised and dismayed at the way this capability has been dismissed from the PCP base specification.  I would have thought that the critical importance of Rapid Recovery would have been immediately recognizable to everyone, and that its inclusion in PCP would have been de rigeur and would have generated no controversy at all.  It is not merely an "optimization" but rather a core feature of the protocol.  I'm ashamed to admit that I didn't notice it was missing until now.

I agree with Mr. Atkinson.  I-D.ietf-pcp-base should not be approved unless the "Rapid Recovery" capability is immediately restored to the specification.  It's too important not to standardize right away, along with the base specification.

> [...]

Either of these would be fine with me too, but I think I would prefer the latter for the sake of simplicity.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 27 Oct 2011 14:36:19 -0700

On 25 Oct, 2011, at 12:47, Reinaldo Penno wrote:

> Hello RJ,
>
> I did not follow up due to the fact that draft-cheshire-pcp- 
> recovery-01 views things from a CPE/home perspective where  
> multicast is pervasive. As you point out, it is trying to recreate  
> NAT-PMP's functionality.
>
> My objection to draft-cheshire-pcp-recovery-01 is that relying on  
> multicast in service provider networks is not practical - although  
> fine for home networks.

The Rapid Recovery text does not say that relying on multicast in  
service provider networks is practical, nor does it say that anyone  
should think that.

What the Rapid Recovery text says is that multicast *is* practical in  
home networks, such as networks where DHCP is used (since a DHCP  
broadcast should generally reach the same set of hosts as an all- 
hosts multicast). Also, such home gateways typically forget all  
dynamic state when rebooted, so they have absolutely no idea who  
their erstwhile clients were, so the *only* option they have is to  
multicast a message to all potential clients saying, "Hey, I'm back."

Therefore multicast is both necessary and sufficient for these devices.

You may not yourself work on low-cost home gateways, but both Apple  
and Linksys do make home gateways for this market, and I would like  
those home gateways to continue to be at least as good as our  
existing NAT-PMP home gateways.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Oct 2011 18:36:48 -0400

> I agree with Mr. Atkinson.  I-D.ietf-pcp-base should not be approved unless the "Rapid Recovery" capability is immediately restored to the specification.  It's too important not to standardize righ…

I am also very concerned about this.  I believe that this mechanism needs to be either (preferably) part of the PCP specification, or approved at the same time as the PCP specification. 

If there are cases for which it is truly infeasible to implement this capability, the specification can make exceptions for those cases.   But the default assumption should be that the rapid recovery capability exists and that server implementations should support it.   Particularly in IPv6.  (I care a bit less about IPv4 as it's at EOL.)

Keith

---

From: james woodyatt <[email-masked]>
Date: Thu, 27 Oct 2011 16:32:15 -0700

> where native IPv6 is deployed.

I will stand up right now and say this is issue yet another reason for me to complain that PCP is not ready to meet requirements derived from REC-48 of RFC 6092 for IPv6 residential gateway simple security functions.

If responding to the "significant pressure" from V6OPS to publish a PCP base specification, so that RFC 6204bis can cite it, is a priority for the PCP working group, then that argues for stopping the current WGLC until the Rapid Recovery capability in I-D.cheshire-pcp-recovery is restored to the PCP base specification.

On the other hand, another option is for PCP to be withdrawn as a candidate for meeting REC-48 of RFC 6092, which would free V6OPS to consider another protocol for that purpose in RFC 6204bis instead.

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Oct 2011 20:02:18 -0400

> On the other hand, another option is for PCP to be withdrawn as a candidate for meeting REC-48 of RFC 6092, which would free V6OPS to consider another protocol for that purpose in RFC 6204bis inste…

I don't think we need two different protocols.  But IMO the emphasis in PCP on accommodating LSNs is misplaced.   Long term, the more important use of PCP is to interface between hosts/applications and IPv6 firewalls... and NATs should be eradicated.  That's not to say that I object to including IPv4/LSN support in PCP, but that feature should not be the primary driver of PCP's design.  PCP should be designed first for v6 and other uses considered secondary.

Keith

---

From: Paul Selkirk <[email-masked]>
Date: Fri, 28 Oct 2011 01:48:04 +0000

Quoth James Woodyatt:
> I have to say I'm surprised and dismayed at the way this capability
> has been dismissed from the PCP base specification.  I would have
> thought that the critical importance of Rapid Recovery would have been
> immediately recognizable to everyone...

And yet you didn't bring it up at Quebec (where I know you were at the
WG meeting), or Prague, or at any point along the line.

> I agree with Mr. Atkinson.  I-D.ietf-pcp-base should not be approved
> unless the "Rapid Recovery" capability is immediately restored to the
> specification.

"Restored" only applies if this is viewed as NAT-PMP-bis, because it was
never in a draft-ietf-pcp-base specification.

> written to include ALL use cases involving either NAT, Firewall, or both.

And yet, I can report that all the energy in the WG has been devoted to
the CGN scenarios (NAT444, DS-Lite, and NAT64, in approximate order of
how much attention they've gotten in the last year). That's probably a
failure to attract the attention of the firewall and CPE folks.

>   please speak up.  I'm open-minded, but the time to put that on the table 

I could turn this around, and say that the time to insist on inclusion
of this feature was last April.

Note that I (as a co-author and implementor) am neither in favor of, nor
opposed to inclusion of Rapid Recovery in the base spec. OTOH, this is
the *third* WGLC on the base spec, which means we (as the WG) need to
take a rather skeptical view of any 11th-hour objections.

				paul

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 27 Oct 2011 21:47:31 -0400

Hello Stuart,

It seems we are in agreement then.

Thanks,

Reinaldo

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Oct 2011 05:08:02 -0400

On 27  Oct 2011, at 21:48 , Paul Selkirk wrote:
> "Restored" only applies if this is viewed as NAT-PMP-bis,
> because it was never in a draft-ietf-pcp-base specification.

If one looks at the draft-ietf-pcp-base (e.g. IANA Considerations, 
transport-layer port number text) in the PCP base specification, 
it is hard to avoid concluding that PCP is a combination of
uPnP and NAT-PMP, and therefore that PCP really is NAT-PMP-bis.  

> failure to attract the attention of the firewall and CPE folks.

That sounds like an admission of process failure on the part of the WG.
It certainly does NOT change the actual WG charter text, which remains
normative on this WG.

> of this feature was last April.

Au Contraire.  

After watching the April PCP list discussion, a reasonable person
would conclude that Rapid Recovery feature EITHER would be included 
in the draft-ietf-pcp-base specification OR that the separate 
Rapid Recovery I-D would go into WG Last Call at the same time 
as the draft-ietf-pcp-base document.  IETF WG list discussions
are binding, unlike in-person meetings, and the list discussion
certainly ended with the impression that there were no unresolved
issues with the Rapid Recovery feature.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Oct 2011 06:00:50 -0400

On 26  Oct 2011, at 00:44 , Paul Selkirk wrote:
> OTOH, a) if we define it for IPv4 multicast, someone
> will surely and immediately request it for IPv6 multicast;

As you predicted, in this morning's email, 
Keith Moore expressed interest in IPv6.

However, Stuart released draft-cheshire-pcp-recovery-02 overnight.
The revised I-D text is IP version agnostic, including language 
about link-local all-nodes multicast for both IPv4 and IPv6.

So the concern quoted at top is resolved at this point.

If other specific issues/concerns exist with draft-cheshire-pcp-recovery,
please make those issues/concerns known to the whole PCP WG list,
ideally with some concrete suggestions on how to resolve any
issues/concerns.

Yours,

Ran

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 15:45:37 +0200

In your previous mail you wrote:

   hosts multicast).

=> I believe you mean DHCPv4.

=> BTW modern UPnP has the same feature too.

Note I have no concern to push the rapid recovery with the DHCP for
PCP server discovery I-D in the "to publish just after" list.

Regards

[email-masked]

PS: by modern I mean in the package where is IGD v2, and if I remember
well at least recommended to be used with IGD v2.
PPS: if the rapid recovery is something nice to have for a CPE in the
case of a CGN I prefer to get the explicit dynamic (and static of
course) mappings saved in a stable storage so there is nothing to
recovery. As in (too) many countries ISPs must log all the mappings by
law, IMHO it is not an issue to provide this. Now you can answer ISPs
could use a stateless solution...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 16:20:33 +0200

On the other hand, another option is for PCP to be withdrawn as a
   candidate for meeting REC-48 of RFC 6092, which would free V6OPS to
   consider another protocol for that purpose in RFC 6204bis instead.
   
-> do you mean UPnP-gw-WANIPv6FirewallControl-v1-Service-20101210.pdf?
(part of UPnP IGD v2)

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 16:23:46 +0200

But IMO the emphasis in PCP on accommodating LSNs is misplaced.

=> there is a simple reason for this: the CPE control is
more than dominated in the current world by UPnP IGD...

Regards

---

From: james woodyatt <[email-masked]>
Date: Fri, 28 Oct 2011 09:49:59 -0700

On Oct 28, 2011, at 7:20 AM, Francis Dupont wrote:
> 
> do you mean UPnP-gw-WANIPv6FirewallControl-v1-Service-20101210.pdf?
> (part of UPnP IGD v2)

RFC 6092 includes a list of marginally viable alternatives, including but not limited to UPnP IGD, which were current at the time of its publication.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Oct 2011 11:38:41 -0700

> existing NAT-PMP home gateways.

On 27 Oct 2011, at 6:47 PM, Reinaldo Penno wrote:

Hello Stuart,

> It seems we are in agreement then.

Excellent. I will incorporate the Rapid Recovery section into draft- 
ietf-pcp-base today.