Subject: Re: [pcp] #38: state maintenance: create a general failure model, discussing how to recover from failures

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 00:36:02 -0000

#38: state maintenance: create a general failure model, discussing how to
recover from failures

Comment(by dthaler@…):

 As discussed at IETF, still need text saying to add mappings on a move.

 Page 36 says:
 > When a PCP client first acquires a new IP
 > address (e.g., reboots or joins a new network), it SHOULD remove
 > mappings that may already be instantiated for that new Internal
 > Address.

 The above only covers the "remove old" state, but if there are
 applications already listening (e.g. on INADDR_ANY), it needs to re-
 register.

 Section 8.7 (Subscriber Renumbering and Address Change Events) doesn't,
 and shouldn't, cover this, since it's not about a client moving into the
 network.

 And section 7.1 (pseudocode for operating a server) only says:
 >      /* Note: the "time_to_send_pcp_request" check below includes:
 >       * 1. Sending the first request
 >       * 2. Retransmitting requests due to packet loss
 >       * 3. Resending a request due to impending lease expiration
 >       * The PCP packet sent is identical in all cases, apart from the
 >       * Suggested External Address and Port which may change over time

 At a miminim the pseudocode in 7.1 needs to be updated, but as I consider
 the pseudocode to be purely an example, I'd also like to see in addition,
 text in the body of some section.

-- 
---------------------------------------+------------------------------------
 Reporter:  Francis.Dupont@…           |       Owner:     
     Type:  enhancement                |      Status:  new
 Priority:  major                      |   Milestone:     
Component:  base                       |     Version:     
 Severity:  -                          |    Keywords:     
---------------------------------------+------------------------------------

Ticket URL: <http://zinfandel.levkowetz.com/wg/pcp/trac/ticket/38#comment:2>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 00:37:24 -0000

Comment(by dthaler@…):

 From IETF:

 Server/proxy reboot:
 * Client periodically refreshes some mapping at whatever the desired
 detection frequency is
 * Client detects server/proxy reboot via Epoch reduction
 * Client resends MAPs/PEERs for current listeners/connections

 Client reboot:
 * Client detects running application listeners/connections
 * Client tells server to delete all mappings
 * Client resends MAPs/PEERs for current listeners/connections

 (Non-PCP client) listener loss:
 * PCP client responsible for detecting and updating server

 Client address addition:
 * Client sends MAPs for IN{6}ADDR_ANY listeners

 Client address loss but has (or gets) another address on same network:
 * Client tells server to delete all mappings for old (THIRD_PARTY) address

 Client address change or network change
 * Both of above

 Most of the above is already in the doc, but not all, e.g., the client
 address addition piece.

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/38#comment:3>
pcp <http://tools.ietf.org/pcp/>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Jun 2011 18:55:09 -0400

Is there a way in PCP request or response to specify 'infinite' lifetime
since 0 already means 'delete'?

In the case of Port Forwarding, current workings is never having to redo
mappings. In other words, if PCP Client sees a reduction in Epoch, it can
refresh/retry mappings, otherwise, it could be silent.

The case in hand is related to a PCP Relay/IWF or intermediate NAT that has
a considerable number of Port Forwarding rules and has to interact with a
PCP Server.

Thanks,

Reinaldo

recover from failures

Comment(by dthaler@Š):

 From IETF:

 Server/proxy
> reboot:

> detection frequency is
 * Client detects server/proxy reboot via Epoch
> reduction

 *
> Client tells server to delete all mappings
 * Client resends MAPs/PEERs for
> current listeners/connections

 * PCP client
> responsible for detecting and updating server

 Client address addition:
 *
> Client sends MAPs for IN{6}ADDR_ANY listeners

 Client address loss but has
> (or gets) another address on same network:
 * Client tells server to delete
> all mappings for old (THIRD_PARTY) address

 Client address change or network
> change
 * Both of above

 Most of the above is already in the doc, but not
> all, e.g., the client
 address addition piece.

--

> Reporter:  Francis.Dupont@Š           |       Owner:     
     Type:
> enhancement                |      Status:  new
 Priority:  major
> |   Milestone:     
Component:  base                       |     Version:
 Severity:  -                          |    Keywords:

pcp
> <http://tools.ietf.org/pcp/>

_______________________________________________

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Jun 2011 17:48:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno
> Sent: Wednesday, June 22, 2011 3:55 PM
> To: pcp issue tracker; [email-masked]
> Cc: [email-masked]
> Subject: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state
> maintenance: create a general failure model, discussing how to recover
> from failures)
> 
> Is there a way in PCP request or response to specify 'infinite'
> lifetime since 0 already means 'delete'?

No.  Nothing lasts forever.

> a considerable number of Port Forwarding rules and has to interact with
> a PCP Server.

It can request a lifetime of 0xFFFFFFFF, which is about 136 years.  The 
PCP server would reasonably put a higher limit on that request, and the
specification currently recommends the PCP server enforce a maximum
of 24 hours:

   8.6. Mapping Lifetime and Deletion

   The PCP client requests a certain lifetime, and the PCP server
   responds with the assigned lifetime.  The PCP server MAY grant a
   lifetime smaller or larger than the requested lifetime.  The PCP
   server SHOULD be configurable for permitted minimum and maximum
   lifetime, and the RECOMMENDED values are 120 seconds for the minimum
   value and 24 hours for the maximum.  It is RECOMMENDED that the
   server be configured to restrict lifetimes to less than 24 hours,
   because they will consume ports even if the internal host is no
   longer interested in receiving the traffic or no longer connected to
   the network.  These recommendations are not strict, and deployments
   should evaluate the tradeoffs to determine their own minimum and
   maximum lifetime values.

-d

> > #38: state maintenance: create a general failure model, discussing
> how
> > to
> recover from failures
> 
> 
> Comment(by dthaler@Š):
> 
>  From IETF:
> 
>  Server/proxy
> > reboot:
> Ticket URL:
> <http://trac.tools.ietf.org/wg/pcp/trac/ticket/38#comment:3>
> pcp

---

From: Dave Thaler <[email-masked]>
Date: Thu, 23 Jun 2011 17:22:46 +0000

Reinaldo Penno writes:
> Is there a way in PCP request or response to specify 'infinite' lifetime since 0
> already means 'delete'?

No.  The IWF can pick a high number to request, and then must refresh at
the interval returned by the server.   That's because the server doesn't
know when the client is no longer there, so in that sense "infinite" is not
a good idea.   We want the state to time out.

-Dave

> ---------------------------------------+--------------------------------
> ---------------------------------------+----
> 
> ---------------------------------------+--------------------------------
> ---------------------------------------+----
> 
> >

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 23 Jun 2011 14:04:07 -0400

Thanks for the answer Dave. I was trying to maintain the same 'static port
forwarding' look and feel in a network where PCP Server is integrated with
subscriber management.

The PCP Client would be a PCP Relay and not really the CPEs.