Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-06.txt

From: [email-masked]
Date: Mon, 12 Jul 2010 01:30:03 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Home Agent Reliability Protocol (HARP)
	Author(s)       : R. Wakikawa
	Filename        : draft-ietf-mip6-hareliability-06.txt
	Pages           : 43
	Date            : 2010-07-12

The home agent can be a single point of failure when Mobile IPv6 and
its compatible protocols are operated in a system.  It is critical to
provide home agent reliability in the event of a home agent crashing
or becoming unavailable.  This would allow another home agent to take
over and continue providing service to the mobile nodes.  This
document describes the problem scope briefly and provides mechanisms
of home agent failure detection, home agent state transfer, and home
agent switching for home agent redundancy and reliability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 14 Jul 2010 17:56:38 -0700

Hi all,

We submitted the newer version of HA reliability document with a lot of editorial updates and small technical update such as IKE resumption interaction support.
Please provide your comments, this document stays as WG doc for 4 years without progress ...

thanks in advance,

ryuji

Begin forwarded message:

> From: [email-masked]
> Date: 2010/07/12 01:30:03GMT-07:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-06.txt
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 24 Jul 2010 22:40:33 +0200

Hi Ryuji, all,

I've read the draft. Overall it seems OK to me. I have some comments and
questions (in no particular order):

Technical:
- Page 4: "if a home agent loses the binding cache state, due to failure
or some other reason, it results in a loss of service for the mobile
nodes", the draft covers more cases, right? I mean, (V)HARP can be used
to provide reliability against a HA that loses the binding cache (e.g.,
because it hangs/halts/breaks down), but also for example against a home
agent that stops being reachable because connectivity problems (that can
be just local to the HA or to the home link where the HA is attached
to). I think this should be better captured in the Introduction.
- Page 5: Home Agent Preference: for the case of VHARP, I guess all the
HA of the set share the same value for DHAAD, but can use a different
one for VHARP purposes, right? I think this is not very clear.
- Page 6: Availability of a redundant home agent set. From current text
I understand that standby home agents cannot be added for an MN after it
bootstraps, but I don't think that is right. Am I not properly
understanding that piece of text?
- Page 7: The text below the "Considerations of IPsec/IKE transfer" item
seems to me contradictory with the text above that and also on page 9.
Is IPsec/IKE state synchronization in scope or not of the document?
- Page 7: Secured Message Exchanges: why MAY there? I'd say MUST be
authenticated (and MAY be encrypted).
- Page 8: IMHO, it is not clear in the draft how standby home agents
coordinate to ensure that only the one with the highest preference value
takes over.
- Page 12: for the scenario depicted in Figure 5, how would the HAs in
region-2 know that the HAs in region-1 have failed and it is not just
that the connectivity between region-1 and region-2 is broken? It might
be possible that region-1 is just not reachable from region-2 but still
from the rest of the Internet.

Editorial:
- IMO, References to RFC3775 should be updated to point to RFC3775bis.
- Page 4: /s/Home Agent Reliability protocol (HARP)/ Home Agent
Reliability Protocol (HARP)/
- Page 4: /s/refers to both a mobile node/refers both to a mobile host/
- Page 4: The definitions of HARP and VHARP do not seem really
definitions to me. I think they should be rewritten slightly.
- Page 4: /s/A home agent which will serve the mobile nodes/A home agent
which can serve the mobile node/
- Page 6: /s/Reliable Home agent service/Reliable home agent service/
- Page 8: I'd rewrite the paragraph starting "If the active home agent
fails"... as it does not seem completely clear to me. For example, it
talks about exchanging information with the active home agent in case
the active home agent fails... how can a standby home agent exchange
info with a node that has failed?
- Page 8: Figure 1, IMO, the rows used to indicate HA1-addr and HA2-addr
may be misleading, as they might seem messages.
- Page 14: /s/SHOULD NOT be set to source and/SHOULD NOT be set to
source or/
- Page 15 and more: /s/multicasted/multicast/
- Page 15: The line "Performed the following functions when a HARP
message is received" needs proper context.
- Page 17 and more: /s/unicasted/unicast/
- Page 17: /s/following verification/following verifications/
- Page 18: /s/The standby home Agent/A standby home agent/
- Page 19: /s/When a home agent need to send/When a home agent needs to
send/
- Page 20: "If a state synchronization message is unicasted" --> in the
previous paragraph it is stated that "A state synchronization message is
only unicasted", so the "If" seems a bit weird here.
- Page 23: It says "If a virtual MAC address [...] is used", but in page
25 it says that "it SHOULD use a virtual MAC address".
- Page 26: /s/non of operations/none of operations/
- Page 27: /s/a mobile node need to manage/a mobile needs to manage/
- Page 28: /s/it MUST proceed/it MUST process/

Regards,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 26 Jul 2010 11:43:06 +0200

Hi Carlos,

Thanks for your review. I finally receive comments in the MEXT list;-)

> to). I think this should be better captured in the Introduction.

I describe the most typical scenario of this protocol.  I will clarify it with your suggestion.

> one for VHARP purposes, right? I think this is not very clear.

It's up to the operation. 
Admin can configure the different set of preferences for HARP operation or use the same preference value of DHAAD. 

> understanding that piece of text?

From the MN point of view, we just use the MIP6 bootstrapping mechanism (split and integrated one) for HA addresses discovery.
MN should re-discover the HA addresses by looking up DNS again, etc...
From the HA point of view, the new HA start sending a HELLO to the HAs in the same HA set.

> Is IPsec/IKE state synchronization in scope or not of the document?

It is out of scope in this document.

> authenticated (and MAY be encrypted).

We had comments that HAs are often placed in the secured link (deep in the operators network).
In these network, the security is just redundant since the link is securely operated.
That's why we relax the security level.

> coordinate to ensure that only the one with the highest preference value

The pref value is exchanged by HELLO, therefore, the HA whose pref is highest should start taking over.

> from the rest of the Internet.

We assume the internal connectivity (between Reg1 and Reg2) is stable. 

> - IMO, References to RFC3775 should be updated to point to RFC3775bis.

-bis is still in draft. I though I should wait for it being RFC.

> - Page 28: /s/it MUST proceed/it MUST process/

I will fix these editorial errors. 

Thanks again!

regards,
ryuji