Subject: [Mipshop] MAP discovery (was Re: AD review of mipshop-4140bis)

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Feb 2008 17:04:53 -0800

I wonder if it makes sense to define MAP discovery along the
lines of Home Agent discovery (RFC 5026 and
draft-ietf-mip6-bootstrapping-integrated-dhc-05). Even though
draft-ietf-mip6-bootstrapping-integrated-dhc-05 assumes the
use of DHCPv6, the basic concept is that the information is
available at the access router and is conveyed to the mobile
node when the mobile node attaches to the access router. One
could use router advertisements instead of DHCP options here.

Comments?

Vijay

Jari Arkko wrote:
> Hesham,
> 
> Thanks for your prompt response. Inline:
> 
>>  > 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.
>>   
> 
> Ok.
> 
>>  > 
>>  > >    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. 
>>   
> 
> 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. 
> 
> 
>>  > 
>>  > >    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.
>>   
> 
> 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.
> 
>>  > >    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.
>>   
> 
> 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...
> 
>>  > 
>>  > 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 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?
> 
>>  > 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. 
>>   
> 
> 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.)
> 
>>  > 
>>  > >    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.
>>   
> 
> Ok.
> 
>>  > 
>>  > >    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.
>>   
> 
> Ok.
> 
>>  > 
>>  > > 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. 
>>   
> 
> 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
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Feb 2008 14:50:05 +0200

First, where's the new version of the draft that was promised? The
deadline has passed and I don't see a new draft... if we want this done,
we need to address the AD review comments.

Second, regarding your proposal Vijay: are you suggesting a separate
document, or something in this document? I think we could debate DHCP
vs. RA topic, but in my mind that's a detail. The big problem I had was
using RAs to construct a flooding scheme throughout the router network.
I do not think that is appropriate, but local distribution via RAs might be.

Jari

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Feb 2008 08:07:39 -0800

> we need to address the AD review comments.

Hesham promised soon after the IETF meeting.

> document, or something in this document? 

No preference.

> I think we could debate DHCP
> vs. RA topic, but in my mind that's a detail. 

The integrated bootstrapping scenario that we developed for
MIP6 is all about getting the information to the access router
when the mobile node attaches to the access router. This could
be the dynamic mechanism for MAP discovery instead of
configuring the MAP information on the access routers. Of course
configuration on the access routers should be allowed too. Once
the MAP information is on the access routers, once could use
either DHCP or router advertisements.

Then there is RFC 5026 which describes the mobile node using
DNS for discovering a home agent (in this case the MAP).

> The big problem I had was

Ack.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 28 Feb 2008 22:06:24 +1000

Jari, 

The next version will be submitted after IETF week, I couldn't get to this
before IETF.  

 > I do not think that is appropriate, but local distribution 

=> Yes and as we agreed the flooding part will be removed. regardless of the
AR configuration mechanism, the spec keeps the RA between the AR and MN. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Feb 2008 13:45:20 +0200

OK

Jari