Subject: [pcp] -07 posted

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 16:46:37 -0700

Version -07 has some, but not all, of the changes recommended last week in
Paul Selkirk's review emails.  I still need another day to integrate the
rest of the edits, or ask questions on them.  My apologies for not having
the time, most of them improve the document (but some make diffs really
hard, so I want to do some of the reorganization changes by themselves, so
diffs are more straight forward).

http://tools.ietf.org/html/draft-ietf-pcp-base-07

Changes include:

A.1.  Changes from draft-ietf-pcp-base-06 to -07

   o  tightened up THIRD_PARTY security discussion.  Removed "highest
      numbered address", and left it as simply "the CPE's IP address".

   o  removed UNABLE_TO_DELETE_ALL error.

   o  renumbered Opcodes

   o  renumbered some error codes

   o  assigned value to IMPLICIT_MAPPING_EXISTS.

   o  UNPROCESSED can include arbitrary number of option codes.

   o  Moved lifetime fields into common request/response headers

   o  We've noticed we're having to repeatedly explain to people that
      the "requested port" is merely a hint, and the NAT gateway is free
      to ignore it.  Changed name to "suggested port" to better convey
      this intention.

   o  Added NAT-PMP transition section

   o  Separated Internal Address, External Address, Remote Peer Address
      definition

   o  Unified Mapping, Port Mapping, Port Forwarding definition

   o  adjusted so DHCP configuration is non-normative.

   o  mentioned PCP refreshes need to be sent over the same interface.

   o  renamed the REMOTE_PEER_FILTER option to FILTER.

   o  Clarified FILTER option to allow sending an ICMP error if policy
      allows.

   o  for MAP, clarified that if the PCP client changed its IP address
      and still wants to receive traffic, it needs to send a new MAP
      request.

   o  clarified that PEER requests have to be sent from same interface
      as the connection itself.

   o  for MAP opcode, text now requires mapping be deleted when lifetime
      expires (per consensus on 8-Mar interim meeting)

   o  PEER OpCode: better description of remote peer's IP address,
      specifically that it does not control or establish any filtering,
      and explaining why it is 'from the PCP client's perspective'.

   o  Removed latent text allowing DMZ for 'all protocols' (protocol=0).
      Which wouldn't have been legal, anyway, as protocol 0 is assigned
      by IANA to HOPOPT (thanks to James Yu for catching that one).

   o  clarified that PCP server only listens on its internal interface.

   o  abandoned 'target' term and reverted to simplier 'internal' term.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 01:11:32 +0100

In your previous mail you wrote:

=> it doesn't matter 0 is IPv6 hop-by-hop because it is an
extension header so must be followed by something which has not 0
as its protocol number. BTW if you raise the problem in the firewall
context we have nothing in PCP to handle multiple protocols and
IMHO it could be a bad idea to provide such a facility...

Thanks

[email-masked]

PS: got the files from the repository...

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 17:28:40 +0100

Hi Dan,

Many thanks for the effort and the energy to update the document.

I have some comments about the new modifs;

* The new NAT-PMP text should be removed to an appendix (or removed from the document). This has been discussed in the past and the agreement was to remove NAT-PMP discussion from the base PCP document. BTW, the NAT-PMP text includes a lot of speculative text (e.g., "relatively short time", "since we expect that this will rapidly become the case,")).

* I still don't see the value of signalling a lifetime associated with errors. The experience has shown in some contexts (e.g., retry-after in SIP) this poses other problems. The current text does not includes any recommended value for each error code. Only "short" or "long lifetime indication" is provided. In such case, this can be supported by the PCP Client without being notified by the PCP Server. In sole contexts (e.g., out of resource, quota exceeded, etc.), the PCP Server does not have "valid" hints to guess when it would honour the requested.  I suggest we roll-back to what has been agreed in -06: i.e., remove the lifetime from the common header. Furthermore, the justification provided in the document is weak (I'm referring to "and it is likely that any future OpCodes will also have a lifetime associated with them,").

Thanks

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 15 mars 2011 00:47
À : [email-masked]
Objet : [pcp] -07 posted

Changes include:

   o  renumbered Opcodes

-d

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:28:55 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 9:29 AM
> To: Dan Wing; [email-masked]
> Subject: NAT-PMP and Lifetime (was RE: [pcp] -07 posted)
> 
> Hi Dan,
> 
> * The new NAT-PMP text should be removed to an appendix (or removed
> from the document). This has been discussed in the past and the
> agreement was to remove NAT-PMP discussion from the base PCP document.
> BTW, the NAT-PMP text includes a lot of speculative text (e.g.,
> "relatively short time", "since we expect that this will rapidly become
> the case,")).

Yes, it should probably be dropped to an appendix and the verbage reduced.

It seemed short enough, though, to not have a separate document on it.

> * I still don't see the value of signalling a lifetime associated with
> errors. The experience has shown in some contexts (e.g., retry-after in
> SIP) this poses other problems. The current text does not includes any
> recommended value for each error code. Only "short" or "long lifetime
> indication" is provided.

Section 8.2 does say:

   These errors are
   considered 'long lifetime' or 'short lifetime', which provides
   guidance to PCP server developers for the value of the Lifetime field
   for these errors.  It is RECOMMENDED that short lifetime errors use
   30 second lifetime and long lifetime errors use 30 minute lifetime.

PCP servers will be deployed on certain networks, and some networks
will need different values.  For example, a 3GPP network might want
different error lifetime values than a FTTH network.  I don't
know what to change in the document.

> In such case, this can be supported by the PCP
> Client without being notified by the PCP Server. In sole contexts
> (e.g., out of resource, quota exceeded, etc.), the PCP Server does not
> have "valid" hints to guess when it would honour the requested.  I
> suggest we roll-back to what has been agreed in -06: i.e., remove the
> lifetime from the common header. Furthermore, the justification
> provided in the document is weak (I'm referring to "and it is likely
> that any future OpCodes will also have a lifetime associated with
> them,").

Agreed that justification is weak.  I removed it for the next version.

This was all added because I had understood we had consensus from
last week's Interim, where it was discussed twice -- once at the 
beginning and again at the end.  But either I mis-understood, or
did the editing wrong, or was supposed to initiate a thread on 
the mailing list (which was the conclusion the first time we 
discussed lifetime in the common header):

Paul's notes at
http://www.ietf.org/mail-archive/web/pcp/current/msg00981.html say:

*BEGIN*
...
Re this change (from A.1):
   o  tightened up text (which was inaccurate) about how long general
      PCP processing is to delay when receiving an error and if it
      should honor OpCode-specific error lifetime.  Useful for MAP
      errors which have an error lifetime.  (This all feels awkward to
      have only some errors with a lifetime.)

Stuart: Why do some errors have lifetimes and some don't?
Dave: Send the question back out to the mailing list to move lifetime
from opcode headers back to the common header, so that even non-opcode
errors can have lifetime.

...

Returning to discussion about lifetime (side effect of #16)
Dave to Francis: Are there any error codes that should not have an
associated lifetime?
Francis: Anything about a packet that is broken (MALFORMED_REQUEST);
the packet will still be broken 30 seconds or 30 minutes later.
Also, by definition, UNSUPP_VERSION means only the first byte of
the packet is parsed.
Dave: If you don't know the value, fill in lifetime 0 or MAXINT.
Stuart: In the common case, most messages (success or failure) have a
natural lifetime, and only the rare and anomolous cases don't have a
natural lifetime.
Francis: Move lifetime to an option for certain errors.
Paul: Error lifetime is a hint to the client; if there are errors for
which lifetime doesn't make sense, client will ignore the hint.
Stuart: Not having lifetime in common header potentially saves 4
bytes; having lifetime in common header simplifies parsing.
Dave: Keep ticket open.
Alain: minimum error lifetime=1
Dave: 0=undefined, maxint=never
Stuart: Server has to give its best guess, "never" isn't acceptable.
Dave: 0=never, server has to pick other value if it doesn't know
Francis: Specify that lifetime is unsigned.
*END*

-d

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 08:29:55 +0100

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 18:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : RE: NAT-PMP and Lifetime (was RE: [pcp] -07 posted)

Med: Ok. Thanks.

Section 8.2 does say:

   These errors are

Med: Signalling a lifetime associated with an error complicates the PCP Server and is useless in some cases. I'm fine to have recommended values for the PCP Client to re-issue the request but not to signal it in the message. 

* A PCP Server out of resource has no hint on what information to put in the answer. If it is overloaded, computing that hint adds extra load. 
* When the quota is reached, what hint do you want a PCP Server want to signal? There is no magic thought. It may make sense to return the maximum allowed port but not a lifetime. 
* Etc.

For the overload case, we might define an option for this purpose (in the lines of what is defined in http://tools.ietf.org/html/draft-bpw-softwire-pcp-dhcp-00#section-3.3 for instance).

Med: What I understood is that the question will be raised in the list but nothing has been discussed since the interim meeting.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 08:32:04 -0700

> Med: Signalling a lifetime associated with an error complicates the PCP
> Server and is useless in some cases. I'm fine to have recommended
> values for the PCP Client to re-issue the request but not to signal it
> in the message.

Are you DISAGREEING or AGREEING that on some networks a PCP
server would want to influence the PCP client to retry errors 
quickly or retry errors slowly?  

Can you educate the working group on the failures you see, or failures
that have been discussed on SIP mailing lists, regarding SIP's retry-in 
that you mentioned elsewhere?  Does SIP's retry-in get returned for 
every error, or just some errors?

As I recall, you did not speak on this point during last week's
interim meeting.  So would like to hear *why* you feel having
the client fully responsible for re-transmitting a request is
a superior design.

There are obviously lots of ways to put the bits on the wire.  Let's
please get the reasons on the table for the different ways to encode
these bits.

> * A PCP Server out of resource has no hint on what information to put
> in the answer. If it is overloaded, computing that hint adds extra
> load.
> * When the quota is reached, what hint do you want a PCP Server want to
> signal? There is no magic thought. It may make sense to return the
> maximum allowed port but not a lifetime.
> * Etc.
> 
> For the overload case, we might define an option for this purpose (in
> the lines of what is defined in http://tools.ietf.org/html/draft-bpw-
> softwire-pcp-dhcp-00#section-3.3 for instance).

So, you're suggesting the "retry-in" value be returned in an Option,
somewhat like a PCP server can return the UNPROCESSED option?  It is
more complicated to return an option than stick a value (or 0) into
a fixed field.  You know it is more complicated.

This does point out that we can't require the server to re-order
options in its response.  (I am really disliking the requirement 
that options be ordered - it feels like a train wreck.)  I will
be changing the ordering requirement so that only requests have
to be ordered; responses can have options in any order.

> Med: What I understood is that the question will be raised in the list
> but nothing has been discussed since the interim meeting.

The lifetime was discussed two times during the interim.  The first
discussion, which was brief, concluded with 'take it to the list'.
Here we are, discussing it.  The second discussion, later in the
interim meeting, seemed to reach a conclusion to have a unified
field.  Hence, -07 put the lifetime into the common header.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:32:00 +0100

options in its response.

=> why? (this doesn't mean I want such a requirement :-)

   (I am really disliking the requirement 
   that options be ordered - it feels like a train wreck.)

=> +1 (but it is not new, I've never believed it was a good idea).

   I will be changing the ordering requirement so that only requests
   have to be ordered; responses can have options in any order.
   
=> don't do that: it makes a response unusable to build a request,
for instance for a renewal.
Just get rid of this option order requirement.

   The second discussion, later in the interim meeting, seemed to
   reach a conclusion to have a unified field.

=> first I don't know if Mohammed was at both parts of the meeting,
second the list is the place where consensus can be built.
So I support Mohammed about the fact this point was not closed.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 10:16:31 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 16, 2011 9:32 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] NAT-PMP and Lifetime (was RE: -07 posted)
> 
> 

A few reasons:

The client has to accept the message, anyway -- it can't issue 
an error.  That is the "can't".

The sole and only reason anyone said they wanted ordering
of requests was to ease processing on the server.  Because
servers are busy.  The client generated its request and
expects a response; if the client is too busy to process
the response, it should not be sending a request.  And clients
are not busy; they are just doing their own work -- they
aren't doing work of hundreds of others.  That is not a
"can't", but explains why it isn't necessary to require the
server to do more work (reordering the Options in its
response) to save effectively no useful CPU cycles on 
the client.

> for instance for a renewal.

Building a response from a request?  Nevermind, I don't want to know.

> Just get rid of this option order requirement.

That is three authors against ordering (you, me, and Stuart).

I'll re-open the ticket #41, and ask the chairs to determine
consensus.  http://trac.tools.ietf.org/wg/pcp/trac/ticket/41

-d