Subject: [pcp] On the State Diagram of pcp-base-19

From: <[email-masked]>
Date: Tue, 3 Jan 2012 15:58:32 +0000

Analyzing the current State-diagram in I-D v19 ( http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 )

                  CLOSE_MSGS or
         (NO_TRAFFIC and EXPIRY) +---------+  NO_TRAFFIC and EXPIRY
                   +------------>|         |<------------+
                   |             |NO_ENTRY |             |
                   |   +---------|         |---------+   |
                   |   |         +---------+         |   |
                   |   |            ^  |             |   |
                   |   | NO_TRAFFIC |  |             |   |
                   |   |         or |  |             |   |
                   |   | CLOSE_MSGS |  |             |   |
                   |   |            |  |             |   |
                   |   | P-R        |  |         M-R |   |
                   |   V            |  |             V   |
                +---------+         |  |         +---------+
            +-->|         |         |  |    M-R  |         |<--+
        P-R |   |    P    |---------|--|-------->|    M    |   | M-R or
            +---|         |         |  |         |         |---+ P-R or
                +---------+         |  |         +---------+   CLOSE_MSGS
                   |   ^            |  |             ^   |
                   |   | P-R        |  |         M-R |   |
                   |   |            |  |             |   |
                   |   |            |  |             |   |
                   |   |            |  |             |   |
                   |   |            |  |             |   |
                   |   |            |  | O-TRAFFIC   |   |
                   |   |            |  V             |   |
                   |   |         +---------+         |   |
                   |   +---------|         |<--------+   |
                   |             |    I    |             |
                   +------------>|         |<------------+
              TRAFFIC and EXPIRY +---------+  TRAFFIC and EXPIRY

I observed that, for example, if the mapping is in the M state and it expires, but the PCP-controlled
device has incoming traffic going through this mapping, the mapping transit from the M to the I state and continues to
receive this incoming traffic, which means that the control of the mapping is taken out from the PCP protocol and is
given to the remote host, that is generating this incoming data.

Considering many aspects of the PCP I-D, IMHO a better diagram state would be:

           CLOSE_MSGS or EXPIRY  +---------+ EXPIRY or M-D-R
                   +------------>|         |<------------+
                   |             |NO_ENTRY |             |
                   |   +---------|         |---------+   |
                   |   |         +---------+         |   |
                   |   |            ^  |             |   |
                   |   | NO_TRAFFIC |  |             |   |
                   |   |         or |  |             |   |
                   |   | CLOSE_MSGS |  |             |   |
                   |   |            |  |             |   |
                   |   | P-R        |  |         M-R |   |
                   |   V            |  |             V   |
                +---------+         |  |         +---------+
            +-->|         |         |  |    M-R  |         |<--+
        P-R |   |    P    |---------|--|-------->|    M    |   | M-R or
            +---|         |         |  |         |         |---+ P-R or
                +---------+         |  |         +---------+   CLOSE_MSGS
                       ^            |  |             ^
                       | P-R        |  |         M-R |
                       |            |  |             |
                       |            |  |             |
                       |            |  |             |
                       |            |  |             |
                       |            |  | O-TRAFFIC   |
                       |            |  V             |
                       |         +---------+         |
                       +---------|         |<--------+
                                 |    I    |
                                 |         |
                                 +---------+

where:
M-D-R is a MAP deletion request

Observations:

1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or PEER) mappings to other states. Instead, for keeping the protocol consistent, EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP mapping in the PCP-controlled device should be oblivious to TRAFIC (inbound or outbound):

1.1. MAP mapping:
EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping going to the NO_ENTRY state. I think the direct transition M -> I* should not be possible.

1.2. PEER mapping:
CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to the NO_ENTRY state. The direct transition P -> I* should not be allowed.

* The transitions M->I and P->I can happen if the mappings go through the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or P mapping's) values of external address and external port in this new I mapping.

Best Regards,

Felipe Miranda Costa

---

From: "Ranganathan T S (rangan)" <[email-masked]>
Date: Wed, 4 Jan 2012 10:25:15 +0530

Hi Felipe Miranda Costa,

Thanks for the review. 

First point:

The I-D mention the following for PEER here
<http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-11.3> :

   If a PEER-created or PEER-managed mapping is not renewed using PEER,

   then it reverts to the NAT's usual behavior for implicit mappings,

   e.g., continued outbound traffic keeps the mapping alive, as per the

   NAT or firewall device's existing policy.  

Second point:

The I-D mention the following for MAP here
<http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-10.3> :

   Mappings created by PCP MAP requests are not
   special or different from mappings created in other ways.  In
   particular, it is implementation-dependent if outgoing traffic
   extends the lifetime of such mappings beyond the PCP-assigned
   lifetime.  PCP clients MUST NOT depend on this behavior to keep
   mappings active, and MUST explicitly renew their mappings as required
   by the Lifetime field in PCP response messages.

Third point:

The paradigm I used to create the diagram is:

*         Give precedence to traffic compared to expiry. 

*         That is if traffic is still flowing when expiry happens, do
not drop the sessions and let it end gracefully.

The diagram added to I-Dv19 satisfies all the above three points.

Thanks,

Rangan.

From: [email-masked] [mailto:[email-masked]]

Sent: Tuesday, January 03, 2012 9:29 PM
To: [email-masked]; Ranganathan T S (rangan)
Subject: On the State Diagram of pcp-base-19

Analyzing the current State-diagram in I-D v19 (
http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 )

                  CLOSE_MSGS or                     

                   |             |NO_ENTRY |             |

                   |   |         +---------+         |   |

                   |   |            ^  |             |   |

                   |   | NO_TRAFFIC |  |             |   |

                   |   |         or |  |             |   |

                   |   | CLOSE_MSGS |  |             |   |

                   |   |            |  |             |   |

                   |   | P-R        |  |         M-R |   |

                   |   V            |  |             V   |

            +-->|         |         |  |    M-R  |         |<--+

CLOSE_MSGS

                   |   ^            |  |             ^   |              

                   |   | P-R        |  |         M-R |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  | O-TRAFFIC   |   |

                   |   |            |  V             |   |       

                   |   |         +---------+         |   |             

                   |             |    I    |             |

 

I observed that, for example, if the mapping is in the M state and it
expires, but the PCP-controlled 

device has incoming traffic going through this mapping, the mapping
transit from the M to the I state and continues to 

receive this incoming traffic, which means that the control of the
mapping is taken out from the PCP protocol and is 

 

Considering many aspects of the PCP I-D, IMHO a better diagram state
would be:

                   |             |NO_ENTRY |             |

                   |   |         +---------+         |   |

                   |   |            ^  |             |   |

                   |   | NO_TRAFFIC |  |             |   |

                   |   |         or |  |             |   |

                   |   | CLOSE_MSGS |  |             |   |

                   |   |            |  |             |   |

                   |   | P-R        |  |         M-R |   |

                   |   V            |  |             V   |

            +-->|         |         |  |    M-R  |         |<--+

CLOSE_MSGS

                       ^            |  |             ^                 

                       | P-R        |  |         M-R |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  | O-TRAFFIC   |   

                       |            |  V             |          

                       |         +---------+         |                

                       +---------|         |<--------+   

                                 |    I    |             

                                 |         |

                                 +---------+  

where:

Observations:

1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or
PEER) mappings to other states. Instead, for keeping the protocol
consistent, EXPIRY should determine the transition from P and M to
NO_ENTRY. A PEER or MAP mapping in the PCP-controlled device should be
oblivious to TRAFIC (inbound or outbound):

1.1. MAP mapping:

EXPIRY or a MAP Deletion Request should be the only causes of a MAP
mapping going to the NO_ENTRY state. I think the direct transition M ->
I* should not be possible.

1.2. PEER mapping:

CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to
the NO_ENTRY state. The direct transition P -> I* should not be allowed.

* The transitions M->I and P->I can happen if the mappings go through
the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course
that, if possible, the PCP Controlled device should keep the same
previous (M or P mapping's) values of external address and external port
in this new I mapping.

Best Regards,

Felipe Miranda Costa

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 6 Jan 2012 16:49:01 -0500

The text in 19 says

"   A PCP client can delete all PCP-created explicit dynamic inbound
   mappings (i.e., those created by PCP MAP requests) that it is
   authorized to delete by sending a PCP MAP request including a zero-
   length THIRD_PARTY Option, zero in the Internal Port field, and zero
   in the Protocol field.
"

So, if a PCP client that has installed many third_party mappings wants to
delete them all, the packet should look like below (napt-44)?

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 1  |0|   MAP       |                  0            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                0                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   0           |                           0                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        0                      |        0                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                        ::ffff:0:0                             |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option Code=1 |  Reserved     |   Option Length=0             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In other words, since third_party option length is zero, there will _no_ 128
bit address in the delete request, correct?

How would a PCP client that has installed many third_party requests delete a
specific one? If option length is zero, nothing can follow, if it is not
zero, it is not a delete.

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 6 Jan 2012 14:38:19 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno
> Sent: Friday, January 06, 2012 1:49 PM
> To: [email-masked]
> Subject: [pcp] Clarification on THIRD_PARTY option
> 
> The text in 19 says
> 

Right.

> specific one? 

The MAP request would have Lifetime = 0, and the THIRD_PARTY option
would have length 16 and the Internal IP Address of the third party
host.

-d

> If option length is zero, nothing can follow, if it is not
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 6 Jan 2012 18:07:48 -0500

Sent from my iPhone

> would have length 16 and the Internal IP Address of the third party

Hummm.. Then why do we need option length zero? For consistency to delete all mappings we should have option length 16 and the 'all ip addresses' in the internal ip address. 

Anyway, not a big deal but there seems to be two ways to delete all mappings.

---

From: "Ranganathan T S (rangan)" <[email-masked]>
Date: Tue, 10 Jan 2012 20:27:31 +0530

Hi Dan et al,

Felipe and I discussed more on this topic offline. We felt that it is
good to have the following note to the diagram in the next version. 

Note: Transition from state M to state I is implementation dependent

This is to take care of the I-D 'Second point' below to its fullest
extent. If this is fine with you can you please update the diagram
notes.

Thanks,

Rangan.

From: Ranganathan T S (rangan) 
Sent: Wednesday, January 04, 2012 10:25 AM
To: [email-masked]'; [email-masked]
Subject: RE: On the State Diagram of pcp-base-19

Hi Felipe Miranda Costa,

Thanks for the review. 

First point:

Second point:

Third point:

Thanks,

Rangan.

                  CLOSE_MSGS or                     

                   |             |NO_ENTRY |             |

                   |   |         +---------+         |   |

                   |   |            ^  |             |   |

                   |   | NO_TRAFFIC |  |             |   |

                   |   |         or |  |             |   |

                   |   | CLOSE_MSGS |  |             |   |

                   |   |            |  |             |   |

                   |   | P-R        |  |         M-R |   |

                   |   V            |  |             V   |

            +-->|         |         |  |    M-R  |         |<--+

                   |   ^            |  |             ^   |              

                   |   | P-R        |  |         M-R |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  |             |   |

                   |   |            |  | O-TRAFFIC   |   |

                   |   |            |  V             |   |       

                   |   |         +---------+         |   |             

                   |             |    I    |             |

 

 

                

                   |             |NO_ENTRY |             |

                   |   |         +---------+         |   |

                   |   |            ^  |             |   |

                   |   | NO_TRAFFIC |  |             |   |

                   |   |         or |  |             |   |

                   |   | CLOSE_MSGS |  |             |   |

                   |   |            |  |             |   |

                   |   | P-R        |  |         M-R |   |

                   |   V            |  |             V   |

            +-->|         |         |  |    M-R  |         |<--+

                       ^            |  |             ^                 

                       | P-R        |  |         M-R |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  |             |   

                       |            |  | O-TRAFFIC   |   

                       |            |  V             |          

                       |         +---------+         |                

                       +---------|         |<--------+   

                                 |    I    |             

                                 |         |

                                 +---------+  

where:

Observations:

1.1. MAP mapping:

1.2. PEER mapping:

Best Regards,

Felipe Miranda Costa

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Jan 2012 08:34:13 -0800

Ok.

-d

> From: Ranganathan T S (rangan) [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 6:58 AM
> To: Dan Wing (dwing)
> Cc: [email-masked]; [email-masked]
> .         Give precedence to traffic compared to expiry.
> 
> .         That is if traffic is still flowing when expiry happens, do
> 1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP
> (or PEER) mappings to other states. Instead, for keeping the protocol
> CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going
> to the NO_ENTRY state. The direct transition P -> I* should not be
> allowed.
> 
> 
> 
> previous (M or P mapping's) values of external address and external
> port in this new I mapping.
> 
> 
> 
> Best Regards,
> 
> 
> 
> Felipe Miranda Costa
> 
> 
> 
>