Subject: [Mip6] Re: Mip6: Comments on draft-ietf-mip6-hareliability-00.txt

From: Brian Haley <[email-masked]>
Date: Wed, 09 Aug 2006 16:46:53 -0400

Fritsche Wolfgang wrote:
> Dear members of the HA reliability DT,
> 
> after the presentation of the version 0 of the
> draft-ietf-mip6-hareliability-00.txt doc during the last IETF Mip6 WG
> meeting, I had a more detailed review on the draft and would like
> provide some comments on it. As I'm not sure if you want at this stage a
> discussion on the Mip6 mailing list, I first send them to you as draft
> contributors, however, feel free to reply on the Mip6 list if found
> appropriate.

I think the Mip6 list is the right place for this discussion as it is a 
working group document.  Changed cc to the list.

I'll just answer #4 for now since I'd need to think to answer them :)

> 1) As I understood the draft, it assumes a redundant HA set comprising a
> single Active HA and one or multiple Standby HAs. However, from an
> operational point of view it could be interesting for economic reasons,
> to have n>1 Active HAs deployed (possibly with some load balancing
> between them) and m Standby HAs, with the flexibility, that each of the
> Standby HAs could replace each of the Active HAs in case of failure.
> This flexibility would reduce the amount of Standby HAs required to m<n.
> With the current draft version I think it won't be possible. 
> One approach could be to allow the Standby HAs to join more redundant HA
> sets simultaneously, using the respective Group-ID to identify for which
> redundant HA set a certain message is destined for. If then e.g. a
> Standby HA becomes Active HA for one redundant HA set / Group-ID, it
> could decrease its preference field for all other redundant HA sets /
> Group-IDs in order to be a less preferred Standby HA there (one may even
> disregard an Active HA for one redundant HA set / Group-ID as possible
> Standby HA in another redundant HA set / Group-ID).
> 
> 2) In the draft it is not clear how a new HA learns about the HAs of a
> certain redundant HA set. Chapter 7.2.3 says here it SHOULD wait a
> particular time to listen for home agent Hello messages of all
> configured Home Agents, and alternative would be to solicit Hello
> message by sending a Hello Request message. However, based on chapter
> 7.2.1 Hello Request messages are unicasted, that is, for this purpose
> the new HA already has to know the IP address of the HA it intends to
> solicit a Hello message for. 
> Based on this I think you assume each HA from the redundant HA set is
> preconfigured with the list of all HAs being member of its redundant HA
> set. If this is correct, it would help to clearly state this somewhere
> at the beginning of the draft, e.g. at the place where the term of
> redundant HA set is introduced.
> 
> 3) In 7.5.3 the draft says "If an Active Home Agent sends the state
> synchronization message whenever the local state information such as
> binding cache changed, the size of the state synchronization message are
> large." I assume rather than "the size of the state synchronization
> message are large" you mean "the number of state synchronization
> messages are high". A single local state information change may not
> require a large state synchronization message, but if for each local
> state information change a separate state synchronization message will
> be sent, their number could easily become high.
> 
> 4)draft-ietf-mip6-hareliability-00.txt and
> draft-ietf-mip6-ha-switch-00.txt are not in the same direction
> concerning which HA will send the HA switch message to the MN.
> draft-ietf-mip6-ha-switch-00.txt assumes this will be the Active HA
> indicating to the MN that it doesn't consider itself any longer suitable
> to serve the MN (e.g. for reasons of overload, upcoming maintenance,
> ...). The HA switch message MUST here be acknowledged by the MN by
> sending a BU for deleting its current registration. 
> draft-ietf-mip6-hareliability-00.txt assumes that mainly the Standby HA
> sends the HA switch message to the MN after it detected a failure of the
> Active HA. Acknowledgement based on sending a BU for deleting its
> current registration makes no sense here, as probably the Active HA
> already failed anyway (which was also discussed on the mailing list).
> Note, based on draft-ietf-mip6-hareliability-00.txt one could send HA
> switch messages also for other reasons than Active HA failure, e.g.
> after an administratively initiated HA SwitchOver or SwitchBack event. 
> Wouldn't it be most flexible to generally allow sending a HA switch
> message from both, the Active and the Standby HA?

I didn't have time before the I-D cutoff to make this change, but it 
will be in the -01 version.

-Brian

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6