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

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Jan 2008 17:35:53 +0200

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 17 Jan 2008 15:06:36 +1000

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

 > below where some inconsistencies with the above have been detected.

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

 > Suggestion: do not restrict the type of address the nodes may use in

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

 > triggered by the reception. 

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

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

 > not just "down" but also "sideways" or even "up" if you draw 

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

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

 > with what I quoted earlier: "MUST perform the binding update 

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

 > >    node MUST use the Mobile IPv6 protocol, as specified in 
 > [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1>].
 > >   
 > 

=> Agreed.

 > 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

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Jan 2008 23:19:26 +0200

Hesham,

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

Ok.

> point you're making above. 

I read the restriction from the text that I quoted: "mobile node
may send a BU containing its LCoA (instead of its RCoA) to 
correspondent nodes, which are connected to its same link". But yes,
maybe I was reading too much into it. Would be good to change the
wording to make sure no one else reads it the way I did. 

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

Ok, but again, please reword (assuming this section stays in to begin
with). It says "re-send", and its unclear whether that means creating a
new RA to send that option, or waiting for the next scheduled/requested
RA and then delivering it.

> but there is nothing wrong with reducing it. It's optional for networks that

Yes, this is a different cases and different sets of participants than the
MN-MAP configuration. But the point that I am making is that there is
significant configuration task in your network to get it to use HMIP. If
its going to be reduced by 1% because you don't need that extra line
in /etc/radvd.conf in your ARs (all of which is probably distributed from
one central repository anyway), its not clear that you are making a
big difference.

But I wouldn't bring this up if I felt the mechanism fits well to the
architecture
of the router advertisements...

> you're thinking about. But for an IETF network for instance, it' ideal. 

I could also see them doing something else, such as simply configuring
this the same way that they configure other parameters. And how many routers
are there?

> would be good to see what the WG thinks. 

Here's the problem. I think we could convince ourselves that we need it
at least in some scenarios. We could repair some of the specific issues
in the scheme. However, my greater concern (that I failed to communicate
in my e-mail) is that I'm not sure we are going to the right architectural
direction by turning RAs into router communication and network flooding
mechanisms. Historically, we've had other means for that. And for good
reasons. It feels like a hack, and I suspect this part would draw attention
in IETF Last Call and IESG review, and I think we would get the document
done much sooner and get a nicer protocol if we dropped this feature.

(If necessary, we could publish an update of the 4140 distribution scheme
in a separate Exp RFC. But since we are going for PS this document I
think we
need to have a fairly high bar in terms of what goes into it.)

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

Ok.

>  > Mobile IPv6 (including, for instance, having a home agent).

Ok.

> the zero lifetime is a good idea. We should discuss removing the guidance of

I'm OK with removing the ping guidance. Why do you believe zero lifetime is
needed? How is its treatment different from omitting the MAP option
altogether?
Or are you trying to model prefix, router, etc. lifetime model with MAPs
as well?

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 21 Jan 2008 14:43:50 +1000

> wording to make sure no one else reads it the way I did. 

=> Ok, I'll make it clear that there is no restriction on the address.

 > RA and then delivering it.

=> Ok, more below.

 > one central repository anyway), its not clear that you are making a

=> Agreed, your point below aside, the config issue is only one benefit, the
other one is being to propagate changes in MAP loading dynamically
(preference field). If you want to discourage or stop MNs from using a MAP,
then the MAP can do that easily and quickly without manual intervention.
However, a manually configured AR would not be able to do that.

 > of the router advertisements...

=> Point taken.

 > need to have a fairly high bar in terms of what goes into it.)

=> Ok, being part of the IESG, you'd know if they will disagree with :).
Personally, I prefer it if there was a concrete reason to say that it's
architecturally bad. I mean, bad architecture decisions are usually bad for
a reason, even if abstract. To expedite things, I'd like to second your
suggestion about having another doc in MIPSHOP for dynamic MAP discovery,
not necessarily using this mechanism, but something that allows routers to
advertise different fields in the MAP option. I think this is useful,
regardless of which mechanism we choose to have.

 > needed? How is its treatment different from omitting the MAP option

=> Well, omitting options from an RA does not invalidate the option. This is
how ND works. So it's best to be explicit.

 > Or are you trying to model prefix, router, etc. lifetime 

=> Yes, because the rules apply to anything. A router may choose to send
half the options for several reasons, BW saving, too many options for the
MTU...etc.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jan 2008 13:54:38 +0200

Hesham,

> However, a manually configured AR would not be able to do that.

Right.

> regardless of which mechanism we choose to have.

The architectural reason is that RAs were never designed for propagation
of information through multiple networks. They lack tools to do this
effectively, including for instance loop detection. I also suspect that
mechanisms with much better performance could be designed, e.g., its not
clear that flooding through RAs is a fast way to tell everyone that a
particular MAP is overloaded.

The RA approach will also tie together the RA process and the MAP
discovery together, e.g., requirements for MAP discovery timeliness will
drive RA frequencies.

Historically, we've had other protocols that handle flooding processes
like this (such as routing protocols). And we've had various service
discovery protocols, all separate from RAs.

> how ND works. So it's best to be explicit.

Ok, I'm convinced.

> half the options for several reasons, BW saving, too many options for the
OK

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 21 Jan 2008 23:20:31 +1000

Thanks Jari, I think we've almost resolved everything. One comment below for
the sake of clarification. 

 > discovery protocols, all separate from RAs.

=> Understood, this mechanism is effectively RIP without the scalability
problem because there is not many entries to handle (number of MAPs in a
domain). I understand the issue you raise but since these are not routes,
the effect of loops is irrelevant because each router picks the option with
minimum distance field. I think it works but I'm inclined to agree with you
to avoid the objections from the IESG. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jan 2008 14:27:55 +0200

Hesham,

> => Understood, this mechanism is effectively RIP 

Yes.

> without the scalability
> domain).

Or so we think at the moment :-)

> I understand the issue you raise but since these are not routes,
> minimum distance field. I think it works 

Assume a looping topology. Then insert a MAP option in one RA, take it
away in the next. What happens?

> but I'm inclined to agree with you
Good, thanks.

Jari