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

From: "Fritsche Wolfgang" <[email-masked]>
Date: Fri, 15 Sep 2006 00:39:06 +0200

Brian,

did you find meanwhile some time to think about comments 1) to 3)? 

Wolfgang

>-----Ursprüngliche Nachricht-----
>Von: Brian Haley [mailto:[email-masked]] 
>Gesendet: Mittwoch, 9. August 2006 22:47
>An: Fritsche Wolfgang
>Cc: Mobile IPv6 Mailing List
>Betreff: [Mip6] Re: Mip6: Comments on 
>draft-ietf-mip6-hareliability-00.txt
>
>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
>

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

---

From: Brian Haley <[email-masked]>
Date: Wed, 27 Sep 2006 16:30:22 -0400

Hi Wolfgang,

> did you find meanwhile some time to think about comments 1) to 3)?

Finally, yes, sorry for the delay.

>>> With the current draft version I think it won't be possible.

I think the Hard Switch case would allow this since the MN would detect 
the HA address change.  Since the Hello messages can be unicast, the HAs 
could be on different subnets.

>>> possible Standby HA in another redundant HA set / Group-ID).

I'm not sure how much text we should add for this special case since the 
draft is just trying to define the HA reliability protocol, not 
deployment.  Maybe one of the other DT members has an opinion?

>>> term of redundant HA set is introduced.

Yes, I would presume some administrator manually configured the 
Redundant Home Agent Set.

>>> synchronization message will be sent, their number could 

You should be able to send multiple Binding Cache Information Options in 
one Synchronization Message, so it could be a large message.  You could 
also send multiple small ones.  The very last sentence of 7.5.3 says the 
first, maybe it's not clear?

Thanks for the comments,

-Brian