Subject: Re: [Mipshop] AD review of mipshop-4140bis

From: Hesham Soliman <[email-masked]>
Date: Mon, 31 Mar 2008 12:36:36 +1100

Hi Jari, all,

Please take a look at the new revision at:
http://www.elevatemobile.com/ietf/draft-ietf-mipshop-4140bis-02.txt

and let me know if you're happy with the way your comments were  
addressed. If you are, I'll submit it.

Cheers,
Hesham

On 17/01/2008, at 1:35 AM, Jari Arkko wrote:
> I have made my AD review of this document. Please find detailed  
> comments
> below.
>
> Overall, I was pleasantly surprised by this specification. It is in
> relatively good shape and while there are issues, there are generally
> minor and mostly solvable by removing the offending parts. I was happy
> with the security parts. The main issues that I have are the flooding
> scheme and the error recovery parts.
>
> I expect some discussion and a new draft revision. After that we can  
> go
> to IETF Last Call.
>
> Technical:
>
> >    This specification allows a mobile node to use more than one  
> RCoA if
> >    it received more than one MAP option.  In this case, the mobile  
> node
> >    MUST perform the binding update procedure for each RCoA.
>
> This MUST seems overly strong. Why would the mobile node be forced to
> use more than one MAP, if it only wanted to use one? See also further
> below where some inconsistencies with the above have been detected.
>
> >    Note that a mobile node may send a BU containing its LCoA  
> (instead of
> >    its RCoA) to correspondent nodes, which are connected to its same
> >    link.  Packets will then be routed directly without going  
> through the
> >    MAP.
> How does this happen? If two nodes sit on the same link and employ
> MAP(s) and home agent(s), they will only see each other's RCoAs and/or
> HoAs. They would see each other's care-of addresses when route
> optimization is attempted. But per your specification above you may  
> not
> attempt it with your local address unless you already know the other
> node is on the same link. Chicken and egg...
>
> Suggestion: do not restrict the type of address the nodes may use in
> route optimization.
>
> >    Upon reception of a router advertisement with the MAP option, the
> >    receiving router MUST copy the option and re-send it after
> >    incrementing the Distance field by one.
> I hope you do not mean re-sending every RA again on another interface,
> triggered by the reception. This would disturb the router's own timing
> and processing of RAs. Please clarify the text to indicate that the
> received RAs are only used for learning the information, and then the
> information is used in the router's own independent RA sending  
> process.
>
> >    The MAP option is propagated towards ARs in its domain.
> I'm not convinced that the dynamic distribution of MAP information is
> useful. First of all, its a very small configuration task compared to
> some of the other things you would have to have in this environment
> (e.g., security policies and key material allowing each mobile node to
> talk to each MAP securely).
>
> Secondly, you seem to be assuming that the MAP is placed in the router
> hierarchy. I would actually expect that a local domain's MAP would be
> placed in the same network as other servers and services exists, not
> necessarily in the aggregated router hierarchy that leads to the
> Internet. This would imply that a MAP RA would have to be distributed
> not just "down" but also "sideways" or even "up" if you draw the  
> router
> placement in the network in a hierarchical manner. Of course, you can
> configure the routers to do this. But at the end of the day, you've
> created a complicated flooding scheme to achieve very little. And  
> there
> may be error modes that we have not thought of.
>
> I would suggest removing the support for dynamic distribution, and
> simply requiring ARs to be configured with this information.
>
> >    A mobile node MUST store the received option(s) in order to  
> choose at
> >    least one MAP to register with.  Storing the options is  
> essential, as
> >    they will be compared to other options received later for the  
> purpose
> >    of the movement detection algorithm.
> >
>
> The "at least one" part is right, in my opinion. But it is  
> inconsistent
> with what I quoted earlier: "MUST perform the binding update procedure
> for each RCoA"
>
> >    If no MAP options are found in the router advertisement, the  
> mobile
> >    node MUST use the Mobile IPv6 protocol, as specified in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1 
> >].
> >
>
> Hmm. I think MUST NOT use HMIP would be more appropriate within the
> specification of how to deal with MAP options. You are assuming that
> whoever implements your spec will also implement and be able to use
> Mobile IPv6 (including, for instance, having a home agent).
>
> > 10. Detection and Recovery from MAP Failures
>
> Paragraph 1 is good, but the rest seems suspect.  For instance, on a
> large domain having every AR send this many pings to the MAP would by
> itself create a problem. And I am not sure this document should be
> dictating a specific mechanisms where service provider infrastructure
> keeps aware of what's up and what's not. I would suggest removing
> everything else except the ability of mobile nodes to react to zero
> lifetime. Or perhaps even that could be removed, if you simply
> recommended that if routers become aware of inability to reach the  
> MAP,
> the MAP option is deleted from RAs.
>
> Editorial:
>
> Please correct the issues from
>
> http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/draft-ietf-mipshop-4140bis-01.nits.txt
>
> >    It is pertinent to note that the use of the MAP does not reply or
> >    assume that a permanent Home Agent is present.
>
> s/reply/rely/
>
> >    The mobile node can communicate with a correspondent node  
> through the
> >    HA, or in a route-optimised manner, as described in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1 
> >].  When
> >    communicating through the HA, the message formats in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1 
> >] can be re-
> >    used.
> s/can be re-used/are used/
>
> > This specification does not provide an algorithm
> >    for the distance-based MAP selection.  However, such an  
> algorithm may
> >    be introduced in future extensions utilising information about  
> the
> >    speed of mobility from lower layers.
> >
> >    ... The following algorithm is simply based on selecting the
> >    MAP that is most distant, provided that its preference value  
> did not
> >    reach a value of zero.  The mobile node operation is shown below:
> >
> >    1.  Receive and parse all MAP options
> An apparent inconsistency. Do you provide a distance-based algorithm  
> or
> not? Note that there might be different algorithms, better/perfect,
> etc., but that was not what the text was claiming.
>
> >    This is achieved by using the RCoA as the identity in IKE Phase 2
> >    negotiation.  This step is identical to the use of the home  
> address
> >    in IKE phase 2.
> >
> I think you mean child SA creation, not phase 2. Phase 2 was an IKEv1
> concept. I see that Vijay noted this as well in his review.
>
> Jari
>
>
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop