Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt

[Francis Dupont <Francis.Dupont at fdupont.fr>]

 In your previous mail you wrote:

   > => IMHO the easiest and fastest way is to go and/or read the agenda of
   > the "ifare" BOF (tomorrow morning).
   
   That's a long walk from my office in the US :)
   
=> this is why I added "read the agenda..." (:-).

   Quoting text from VijayD on another list since it seems related:
   
   "I am not sure how IFARE is related to this. IFARE does not address
   transferring IPsec state. It is more explicitly moving a client to
   another VPN gateway (load balancing, failover, etc..). So transferring
   IPsec state is out of scope for IFARE also."
   
   After reading the proposed charter that seems correct to me too.
   
=> I don't know what is exactly "transferring IPsec state" but low
latency failover (something is the slide in the screen now at ifare
session) should include something at least close...

   > => collaboration can help, no collaboration is likely a source of
   > slow down.
   
   If IFARE turns-into a WG and decides to work on HA IPsec failover that's 
   great, it can specify a new protocol that supercedes HA-switch, but the 
   HA-switch draft is pretty complete today.
   
=> I believe that nobody wants two competitive protocols doing the same
thing... BTW I checked at the beginning of the session whether such
collaboration was in the agenda and the answer was yes (BTW I specified
the mobile IP cloud because of the proposed merge of mip6/nemo/monami6).

   > => IMHO this is not so clear:
   >  - the current HA can be clever enough to avoid the ND-proxy issue because
   >   it knows exactly what should happen.
   >  - when you move to another home link there is not possible ND-proxy issue.
   > So the problem is not a wording problem as I believed, perhaps we need
   > an explicit "break-before-make is authorized" notification.
   
   The other HA *should* be smart and not require the break, but we can't 
   assume that's the case.

=> but the current HA has a better knowledge of the context so IMHO
we should use it to control the way the switch could be done when
some ways can raise issues.

   The only alternative right now (finding a new 
   HA when yours isn't responding) behaves the same way, ha-switch is just 
   a way to speed-up that process.

=> in fact I don't believe it is true because the client doesn't know if
things were broken for the HA... So you can have a HA only working for
the ND-proxy part and messing the DAD from the other HA! Of course
this is not really related to the HA-switch protocol (i.e., there is
nothing we can do so nothing to put in the document).

   The ha-reliability soft switch mode is more desirable of course.
   
=> yes but the world is not (yet :-) perfect.

Thanks

Francis.Dupont at fdupont.fr

_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6