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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Dear Ryuji,

Thanks for tyour reply. Some comments below.

On Mon, 2010-07-26 at 11:43 +0200, Ryuji Wakikawa wrote:
> Hi Carlos,
> 
> Thanks for your review. I finally receive comments in the MEXT list;-)
> 
> On 2010/07/24, at 22:40, Carlos Jesús Bernardos Cano wrote:
> 
> > 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.
> 
> I describe the most typical scenario of this protocol.  I will clarify it with your suggestion.
> 
> 
> > - 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.
> 
> 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. 
> 
> > - 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?
> 
> 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.

Then I think it is not very clear in the text. From your response, I
understand that for VHARP, HAs can be added anytime, as for HARP, the MN
would need to re-discover the HAs in order to add some after
bootstrapping, right?

> 
> 
> > - 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?
> 
> It is out of scope in this document.

Then I'd suggest to fix the text to make it clear.

> 
> 
> > - Page 7: Secured Message Exchanges: why MAY there? I'd say MUST be
> > 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.

Then I'd explain this in the text.

> 
> 
> > - 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.
> 
> The pref value is exchanged by HELLO, therefore, the HA whose pref is highest should start taking over.

How are possible conflicts solved? what happens if two HAs
simultaneously try to take 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.
> 
> We assume the internal connectivity (between Reg1 and Reg2) is stable.

Isn't that a strong requirement? Anyway, I think this should be
explicitly mentioned in the text.

>  
> 
> > Editorial:
> > - 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.

I'm not sure it makes sense to submit a draft that references an RFC
that is becoming obsolete anytime soon.

Thanks,

Carlos

> 
> > - 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/
> 
> I will fix these editorial errors. 
> 
> Thanks again!
> 
> regards,
> ryuji
> 
> 
> > 
> > Regards,
> > 
> > Carlos
> > 
> > On Wed, 2010-07-14 at 17:56 -0700, Ryuji Wakikawa wrote:
> >> 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: [e-mail]
> >>> Date: 2010/07/12 01:30:03GMT-07:00
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-06.txt
> >>> 
> >>> 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.
> >>> _______________________________________________
> >>> MEXT mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mext
> >> 
> >> _______________________________________________
> >> MEXT mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mext
> > 
> > -- 
> > Carlos Jesús Bernardos Cano     http://www.netcoms.net
> > GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> 

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