[lacnog] [LAC-TF] Fwd: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01

[Fernando Gont]

Hola, Erick,

On 09/22/2014 04:51 PM, Erick Lobo Marín wrote:
> Fernando: 
> 
> Cómo se ajusta el http://tools.ietf.org/html/rfc7031#section-7 a esta
> propuesta?

Lo especificado en RFC7031 apunta a tener un protocolo RFC7031 descirbe
requisitos para especificar un protocolo que permita intercabiar
informacion entre dos servidores DHCPv6, de modo que ambos siempre
tengan sincronizada la info sobre los "leases" de direcciones IPv6.

Esa "sincronizacion de informacion" supone ser bastante exacta... pero
requiere de la especificacion, e implementacion de un nuevo protocolo.

Lo que nosotros hicimos en nuestro I-D es especificar un algoritmo que
debe correr en los servidres DHCPv6, para que la asignacion de
direcciones sea deterministica. Es decir, a un mismo cliente, siempre se
le va a asignar la misma direccion IPv6... por mas que se use uno u otro
servidor DHCPv6. Nuestro I-D no requiere de la especificacion ni
implementacion de ningun protocolo nuevo. Y digamos que los
requerimentos especifiados en RFC7031 no le aplican, ya que se trata de
algo mas bien "lightweight".

Ahora, respondiendo especificamente tu pregunta, y citando la seccion
correspondiente de RFC7031:

>    1.  The number of supported partners must be exactly two, i.e., there
>        are at most two servers that are aware of a specific lease.

Nuestro I-D no tiene limites en este sentido. Podrias utilizar 10, 100,
o 1000 servidores DHCPv6, si asi lo deseas.



>    2.  For each prefix or address pool, a server must not participate in
>        more than one failover relationship.

Esto no aplica a nuestro I-D.



>    3.  The defined protocol must support the m-to-1 model (i.e., one
>        server may form more than one relationship), but an
>        implementation may choose to implement only the 1-to-1 model
>        (i.e., everything from one server is backed on another).

Esto no aplica a nuestro I-D.



>    4.  One partner must be able to continue serving leases offered by
>        the other partner.  This property is also sometimes called "lease
>        stability".  The failure of either failover partner should have
>        minimal or no impact on client connectivity.  In particular, it
>        must not force the client to change addresses and/or change
>        prefixes delegated to it.  Lease stability has the aim of
>        avoiding disturbance to long-lived connections.

Nuestro I-D provee lease-stability, ya que el algoritmo hace que la
asignacion de direcciones sea deterministica.



>    5.  Prefix delegation must be supported.

Esto no aplica a nuestro I-D.



>    6.  Use of the failover protocol must not introduce significant
>        performance impact on server response times.  Therefore,
>        synchronization between partners must be done using some form of
>        lazy updates (see Section 5.2.2).

Esto no aplica a nuestro I-D, y que el mismo no necesita de ningun nuevo
protocolo...


>    7.  The pair of failover servers must be able to recover from a
>        server down failure (see Section 5.1.1).
> 
>    8.  The pair of failover servers must be able to recover from a
>        network partition event (see Section 5.1.2).

Nuestro I-D permite esto.



>    9.  The design must allow secure communication between the failover
>        partners.
> 
>    10. The definition of extensions to this core protocol should be
>        allowed, when possible.

Estos dos requerimentos no aplican, ya que nuestro I-D no precisa de un
nuevo protocolo.


Al margen, te diria que lo que especificamos nosotros, en un mes lo
podrias tener andando. Mientras que completar la especificacion, e
implementar el protocolo para sincronizacion de estado entre servidores
DHCPv6 llevara mas tiempo..

Mira, sin ir mas lejos, el documento de diseño para tal protocolo:
<http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-failover-design-04.txt>..
y en particular la pagina 34...

Saludos cordiales, y gracias!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492