Subject: [pcp] PCP Issue #1, Epoch

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Jan 2011 09:10:34 -0800

http://trac.tools.ietf.org/wg/pcp/trac/ticket/1 says:

  > PCP design for both servers that flushes context on reboot vs 
  > servers that maintain state across reboot
  > -Ie, with or without stable storage
  > -Usually (not always) CPE vs CGN
  >   * Epoch mechanism is useful in the flush case, not for 
  >     stable storage case
  >   * Proposed resolution:
  > -Keep Epoch

I believe we have consensus to keep the Epoch.

  > -Maybe as a server-side IE?

On the last point, "maybe as server-side IE?", there are two ways I see to
encode the Epoch:

1. as currently described in draft-ietf-pcp-base-02, which is that every PCP
response contains the Epoch.  This means *every* OpCode, including new
Opcodes we might define in the future, would include the Epoch.  The layout
is currently this (see **):

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver=1 |reserve|R|   Opcode    |  Reserved     |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ** |                             Epoch                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) OpCode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Informational Elements                 :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. remove the Epoch from the common PCP header, and move it to be part of
the PIN44, PIN64, PIN46, and PIN66 OpCodes, like this (see **):

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |          Reserved                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ** |                             Epoch                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Pinhole Internal IP address (32 or 128, depending on OpCode)  :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Requested external IP address (32 or 128, depending on OpCode):
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Requested lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        internal port          |   requested external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The advantage of moving the Epoch into the PIN* OpCodes is we free up 4
bytes of space for future OpCodes that might not care about the Epoch.  If
they do care about the Epoch, those future OpCodes can define the Epoch as
part of their packet format.

If I don't hear objections, I will be doing (2) in -03.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2011 15:00:05 +0100

=> as none of the two ways is about an option (aka IE) I can't see how
this is related to the question (:-).

   1. as currently described in draft-ietf-pcp-base-02, which is that every PCP
   response contains the Epoch.  This means *every* OpCode, including new
   Opcodes we might define in the future, would include the Epoch.

=> if we keep the Epoch with its current meaning it should be in the
common header (i.e., 1). I can't see an advantage to put it in each opcode.
(nor I can see an advantage in any gratuitous change)

   The advantage of moving the Epoch into the PIN* OpCodes is we free up 4
   bytes of space for future OpCodes that might not care about the Epoch.

=> 'might not care about the Epoch' is against the design of the Epoch.

=> I object.

Regards

[email-masked]

PS: I have a concern about the term Epoch: it means both the Epoch itself
and the seconds since start of the Epoch (SSSOE), i.e., the same word is
used for absolute and relative views, leading to confusion and/or ambiguity.

---

From: <[email-masked]>
Date: Thu, 6 Jan 2011 18:19:32 +0800

+1, I agree with Francis that 'some future OpCodes might not care about the Epoch' is against the design of the Epoch. 

BR,
Xiaohong

|-----邮件原件-----
|发件人: Francis Dupont [mailto:[email-masked]] 
|发送时间: 2011年1月5日 22:00
|收件人: Dan Wing
|抄送: [email-masked]
|主题: Re: [pcp] PCP Issue #1, Epoch
|
| In your previous mail you wrote:
|
|     > -Maybe as a server-side IE?
|   
|   On the last point, "maybe as server-side IE?", there are 
|two ways I see to
|   encode the Epoch:
|   
|=> as none of the two ways is about an option (aka IE) I can't 
|see how this is related to the question (:-).
|
|   1. as currently described in draft-ietf-pcp-base-02, which 
|is that every PCP
|   response contains the Epoch.  This means *every* OpCode, 
|including new
|   Opcodes we might define in the future, would include the Epoch.
|
|=> if we keep the Epoch with its current meaning it should be 
|in the common header (i.e., 1). I can't see an advantage to 
|put it in each opcode.
|(nor I can see an advantage in any gratuitous change)
|
|   The advantage of moving the Epoch into the PIN* OpCodes is 
|we free up 4
|   bytes of space for future OpCodes that might not care about 
|the Epoch.
|
|=> 'might not care about the Epoch' is against the design of the Epoch.
|   
|   If I don't hear objections, I will be doing (2) in -03.
|   
|=> I object.
|
|Regards
|
[email-masked]
|
|PS: I have a concern about the term Epoch: it means both the 
|Epoch itself and the seconds since start of the Epoch (SSSOE), 
|i.e., the same word is used for absolute and relative views, 
|leading to confusion and/or ambiguity.
|
|