Re: [BEHAVE] [pcp] last CGN requirements

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange-ftgroup.com
> Sent: Tuesday, March 15, 2011 5:14 AM
> To: Francis Dupont; pcp@ietf.org
> Subject: Re: [pcp] last CGN requirements
> 
> Hi all,
> 
> REQ-6 is an operational requirement which require more elaboration:
> e.g., how an address pool is defined? Is there any hold-timer for the
> re-use of the address pool?

There really isn't a /need/ for two address pools.  Rather, there is a
need to not re-use an address within "some time period".  I don't know
the time period.  It needs to be discussed.  For EXAMPLE, let's say
there is a CGN that crashes and takes 20 minutes to boot -- could it
reasonably re-use the same IP address pool?  2 minutes to boot?  4
minutes?  What is the amount of time needed.  

Today when ISPs force subscribers to change IP addresses, do they wait
a day or an hour or a minute before re-using the IP address for another
subscriber?

> For operational requirements, I would prefer having something as what
> is documented in http://tools.ietf.org/html/draft-xu-behave-stateful-
> nat-standby-06.
> 
> In draft-xu-behave-stateful-nat-standby-06, you may read this
> requirement which I would like see integrated in the CGN requirement I-
> D:
> 
>    "Port forwarding entries SHOULD be stored in permanent storage
>    whatever the deployed redundancy mode."

If a different address pool is going to be one of the requirements,
though, such permanent storage serves no purpose.

Essentially, I think we need to up-level the requirement to what
we want to see on the wire, rather than how it should be implemented
in the CGN.

-d

> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
> Francis Dupont
> Envoyé : mardi 15 mars 2011 11:20
> À : pcp@ietf.org
> Objet : [pcp] last CGN requirements
> 
> Printing the new base-07, I am reading the new CGN requirement draft
> (named draft-ietf-behave-lsn-requirements-01.txt but LSN was replaced
> by CGN everywhere at the exception of the title).
> I can get:
> 
>    REQ-6:  When a CGN loses state (due to a crash, reboot, failover to
> a
>       cold standby, etc.), it MUST start using a different external
>       address pool.
> 
>    Justification:  This is necessary in order to prevent collisions
>       between old and new mappings and sessions.  It ensures that all
>       established sessions are broken instead of redirected to a
>       different peer.  The previous address pool MAY of course be
> reused
>       after a second loss of state.
> 
> Three comments:
>  - the MUST applies to all mappings: static, explicit dynamic (i.e.,
>   instantiated by PCP) and implicit dynamic.
> 
>  - it does not say something about the use of stable/persistent storage
>   to remove the condition (i.e., the when).
> 
>  - it is a pure operational requirement, for instance the MAY does not
>   make sense from a security point of view for long term mappings,
>   i.e., static or explicit dynamic.
> 
> There are other interesting points (REQ-1 for instance) but IMHO it is
> unfinished: logging section does not use the fact EIM is required for
> instance.
> 
> Regards
> 
> Francis.Dupont@fdupont.fr
> 
> PS: Simon, I believe you want more comments?
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp