<div dir="ltr">Excelente, muchas gracias.</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Atentamente,<div>Erick Lobo</div><div><br></div><div>lgD</div></div></div>
<br><div class="gmail_quote">2014-09-22 14:43 GMT-06:00 Fernando Gont <span dir="ltr"><<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hola, Erick,<br>
<br>
On 09/22/2014 04:51 PM, Erick Lobo Marín wrote:<br>
> Fernando:<br>
><br>
> Cómo se ajusta el <a href="http://tools.ietf.org/html/rfc7031#section-7" target="_blank">http://tools.ietf.org/html/rfc7031#section-7</a> a esta<br>
> propuesta?<br>
<br>
Lo especificado en RFC7031 apunta a tener un protocolo RFC7031 descirbe<br>
requisitos para especificar un protocolo que permita intercabiar<br>
informacion entre dos servidores DHCPv6, de modo que ambos siempre<br>
tengan sincronizada la info sobre los "leases" de direcciones IPv6.<br>
<br>
Esa "sincronizacion de informacion" supone ser bastante exacta... pero<br>
requiere de la especificacion, e implementacion de un nuevo protocolo.<br>
<br>
Lo que nosotros hicimos en nuestro I-D es especificar un algoritmo que<br>
debe correr en los servidres DHCPv6, para que la asignacion de<br>
direcciones sea deterministica. Es decir, a un mismo cliente, siempre se<br>
le va a asignar la misma direccion IPv6... por mas que se use uno u otro<br>
servidor DHCPv6. Nuestro I-D no requiere de la especificacion ni<br>
implementacion de ningun protocolo nuevo. Y digamos que los<br>
requerimentos especifiados en RFC7031 no le aplican, ya que se trata de<br>
algo mas bien "lightweight".<br>
<br>
Ahora, respondiendo especificamente tu pregunta, y citando la seccion<br>
correspondiente de RFC7031:<br>
<br>
> 1. The number of supported partners must be exactly two, i.e., there<br>
> are at most two servers that are aware of a specific lease.<br>
<br>
Nuestro I-D no tiene limites en este sentido. Podrias utilizar 10, 100,<br>
o 1000 servidores DHCPv6, si asi lo deseas.<br>
<br>
<br>
<br>
> 2. For each prefix or address pool, a server must not participate in<br>
> more than one failover relationship.<br>
<br>
Esto no aplica a nuestro I-D.<br>
<br>
<br>
<br>
> 3. The defined protocol must support the m-to-1 model (i.e., one<br>
> server may form more than one relationship), but an<br>
> implementation may choose to implement only the 1-to-1 model<br>
> (i.e., everything from one server is backed on another).<br>
<br>
Esto no aplica a nuestro I-D.<br>
<br>
<br>
<br>
> 4. One partner must be able to continue serving leases offered by<br>
> the other partner. This property is also sometimes called "lease<br>
> stability". The failure of either failover partner should have<br>
> minimal or no impact on client connectivity. In particular, it<br>
> must not force the client to change addresses and/or change<br>
> prefixes delegated to it. Lease stability has the aim of<br>
> avoiding disturbance to long-lived connections.<br>
<br>
Nuestro I-D provee lease-stability, ya que el algoritmo hace que la<br>
asignacion de direcciones sea deterministica.<br>
<br>
<br>
<br>
> 5. Prefix delegation must be supported.<br>
<br>
Esto no aplica a nuestro I-D.<br>
<br>
<br>
<br>
> 6. Use of the failover protocol must not introduce significant<br>
> performance impact on server response times. Therefore,<br>
> synchronization between partners must be done using some form of<br>
> lazy updates (see Section 5.2.2).<br>
<br>
Esto no aplica a nuestro I-D, y que el mismo no necesita de ningun nuevo<br>
protocolo...<br>
<br>
<br>
> 7. The pair of failover servers must be able to recover from a<br>
> server down failure (see Section 5.1.1).<br>
><br>
> 8. The pair of failover servers must be able to recover from a<br>
> network partition event (see Section 5.1.2).<br>
<br>
Nuestro I-D permite esto.<br>
<br>
<br>
<br>
> 9. The design must allow secure communication between the failover<br>
> partners.<br>
><br>
> 10. The definition of extensions to this core protocol should be<br>
> allowed, when possible.<br>
<br>
Estos dos requerimentos no aplican, ya que nuestro I-D no precisa de un<br>
nuevo protocolo.<br>
<br>
<br>
Al margen, te diria que lo que especificamos nosotros, en un mes lo<br>
podrias tener andando. Mientras que completar la especificacion, e<br>
implementar el protocolo para sincronizacion de estado entre servidores<br>
DHCPv6 llevara mas tiempo..<br>
<br>
Mira, sin ir mas lejos, el documento de diseño para tal protocolo:<br>
<<a href="http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-failover-design-04.txt" target="_blank">http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-failover-design-04.txt</a>>..<br>
y en particular la pagina 34...<br>
<br>
Saludos cordiales, y gracias!<br>
--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a><br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</blockquote></div><br></div>