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

[Erick Lobo Marín]

Excelente, muchas gracias.

Atentamente,
Erick Lobo

lgD

2014-09-22 14:43 GMT-06:00 Fernando Gont <fgont at si6networks.com>:

> 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 at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20140922/5ddfa0e6/attachment.html>