Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt

From: Norman Sardella <[email-masked]>
Date: Fri, 07 Jun 2013 14:42:29 -0400

Mohamed

I have a question in your examples in section 2.12,
about returning remaining idle-timeout on MAP delete response
 >                |--------------------------------->|
 >                |  PCP MAP Response (Lifetime=     |
 >                |          remaining idle-timeout) |

Some LSN implementations are incapable of returning the remaining
lifetime because  each flow creates a separate NAT translation
based of the PCP master created NAT entry.
In this case, which of the other NAT entries would we pick to return an 
idle-timeout?

How are  PCP clients expected to use the lifetime in delete mappings 
responses?
Should a PCP server return 0, return idle-timeout value, or the age
remaining when the PCP master NAT entry was created?

Thanks
Norman Sardella

On 05/30/2013 05:36 AM, [email-masked] wrote:
> Dear all,
>
> This updated version includes two additional use case suggested by Dan.
>
> Don't hesitate to share any use case you think it is worth to be documented this I-D.
>
> Cheers,
> Med
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : jeudi 30 mai 2013 11:27
> À : [email-masked]
> Objet : I-D Action: draft-boucadair-pcp-flow-examples-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : PCP Flow Examples
> 	Author(s)       : Mohamed Boucadair
> 	Filename        : draft-boucadair-pcp-flow-examples-01.txt
> 	Pages           : 32
> 	Date            : 2013-05-30
>
> Abstract:
>     This document provides a set of examples to illustrate PCP
>     operations.  It is a companion document to the base PCP
>     specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-flow-examples-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 8 Jun 2013 15:09:34 +0000

>In this case, which of the other NAT entries would we pick to return an

How does your implementation work? Does the mater entry have a timer of
its own or packets hitting the derived sessions refresh the main entry?

Does each derived entry have a timer of its own?

>remaining when the PCP master NAT entry was created?

See above. This is implementation specific and to help answer this
questions we need to understand how your implementation work.

>> De : [email-masked]
>>[mailto:[email-masked]] De la part de
>>[email-masked]

---

From: Norman Sardella <[email-masked]>
Date: Sat, 08 Jun 2013 20:07:31 -0400

Hi Reinaldo , see comments below
> its own or packets hitting the derived sessions refresh the main entry?
Each flow(connection) to external address/port has its own NAT entry 
with its own timer. The master from the PCP map openrs anan external 
address/port to an internal host and has its own timer.

> Does each derived entry have a timer of its own?
Each derived entry has its own timer.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 11 Jun 2013 17:42:49 +0000

Hi Norman,

this point is very interesting. Although I've seen similar implementations
before, i.e.,  PCP was built on top of existing Load-Balancing/FW code -
actually PCP was used for load-balancing, nothing related to NAT (but that
is for another time), I believe first you will need to decide on a few
design things.

Q: If the master entry times out, will you forcefully nuke all derived
entries?

A:  If yes, then all your timer replies should probably be based on the
master entry timer.

Q: Does the master entry only times out after the last derived session
entry times 
out? In other words, indirectly (or directly) packets matching derived
session refresh master entry.

A: Then all your timer replies should probably be based on 2hrs and 4
minutes, which would be the idle-timeout of a derived TCP session if
packets stopped flowing 'now'. Or the equivalent for UDP/ICMP, etc.

Another important aspect is whether you would "freeze" the master entry
after a delete message is received. I've seen implementations where after
the PCP MAP delete message is received, no more derived sessions are
created since mapping is in "deleting" state. But this is implementation
specific.

Thanks,

Reinaldo