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

["Vijay Devarapallli" <[e-mail]>]

Hesham,

We need to add a paragraph that explains what changed from RFC 4140,
and why it is now a Proposed Standard instead of Experimental. The IESG
wanted something along these lines for 4068bis. I suspect they would want
such a paragraph/section even for 4140bis.

Vijay

On Sun, Mar 30, 2008 at 6:36 PM, Hesham Soliman
<[e-mail]> wrote:
> 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
>  > [e-mail]
>  > https://www1.ietf.org/mailman/listinfo/mipshop
>
>  _______________________________________________
>  Mipshop mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/mipshop
>
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop