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

["Hesham Soliman" <[e-mail]>]

Thanks Jari. Folks please join the discussion with any comments so I can
update the draft.

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

=> Agreed. I think it's poor wording. We should s/MUST/would.

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

=> Is there a restriction in the doc today? I agree with your logic just
trying to figure out what needs to be updated. Perhaps we should clarify the
point you're making above. 

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

=> No, the text talks about "copying *the option* and re-send it", not the
RA.

 > >    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).

=> Yes but none of these need to be configured between the AR and the MAP.
These are e2e configurations between the MAP and MN. Of course in terms of
router config, the AR needs a lot more material for things other than HMIP,
but there is nothing wrong with reducing it. It's optional for networks that
benefit from it.

 > 
 > 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

=> Yes, I don't think this mechanism is good for the types of networks
you're thinking about. But for an IETF network for instance, it' ideal. 


 > I would suggest removing the support for dynamic distribution, and
 > simply requiring ARs to be configured with this information.

=> Hmm. please see above and let us know if other scenarios make sense.
Given that it's optional and may be useful in some deployments I'm a bit
reluctant to quickly remove the only dynamic method we have. Of course it
would be good to see what the WG thinks. 

 > 
 > >    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"

=> Right, so changing the MUST would fix this.

 > 
 > >    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).

=> Agreed.

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

=> I've actually looked into this for a real mobile deployment and it's not
that bad to send pings. But anyway, I don't agree that the spec is
"dictating" this, it's only a guidance. In any case, I don't think removing
the zero lifetime is a good idea. We should discuss removing the guidance of
using ping. 

 > 
 > Editorial:

=> Ok to all. 

Hesham

 > 
 > Please correct the issues from
 >   
 > http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/d
 > raft-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://www1.ietf.org/mailman/listinfo/mipshop