Subject: RE: [mobile-ip] HMIPv6-next steps

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 17 Sep 2002 19:10:49 +0200

Thanks for the comments, we will look into them.

The highest priority now is to make sure that
HMIPv6 will work with the recent spec changes. 
We will send a note to the list on the security
requirements shortly. 

Hesham

  > -----Original Message-----
  > From: Behcet Sarikaya [mailto:[email-masked]]
  > Sent: Tuesday, September 17, 2002 7:08 PM
  > To: Hesham Soliman (EAB)
  > Cc: [email-masked]
  > Subject: Re: [mobile-ip] HMIPv6-next steps
  > 
  > 
  > Hesham,
  >   I agree with the decision to remove the extended mode.
  > As for the comments, I suggest that you look into the open issues I 
  > tried to point out in my draft on LMM architectures, the 
  > most important 
  > one being how to detect domain changes, etc. The pointer to 
  > version 1 is 
  > in one of my previous messages.
  > 
  > Regards,
  > 
  > Hesham Soliman (EAB) wrote:
  > 
  > >Hi all, 
  > >
  > >After some discussion with the chairs we agreed
  > >that we will send an update on HMIPv6 to the 
  > >list FYI and comments. 
  > >
  > >A couple of people have indicated that it might
  > >be good to put extended mode in a separate draft,
  > >partly because it is helpful for nemo and partly
  > >because it will need some more work to accomodate
  > >the latest changes in the MIPv6 base. 
  > >
  > >Extended mode might be useful for nemo, but it's too
  > >early to tell right now, for this reason it is hard
  > >to keep it in a MIP WG document. On the other hand, 
  > >it is also useful for removing the extra tunnel
  > >when CNs do not use/implement RO. 
  > >
  > >What we're trying to do is to finish the draft ASAP. 
  > >For this reason, and given comments on the list, the
  > >chairs suggested that we remove extended mode for 
  > >now and proceed with Basic mode only. If we later
  > >agree on a nice solution for using extended mode
  > >with MNs implementing RR with CNs, then we can proceed
  > >with a separate draft. 
  > >
  > >We are now working on a new revision that will reflect
  > >these changes, your feedback is welcome as usual.
  > >
  > >Hesham
  > >
  > >  
  > >
  > 
  > -- 
  > Behcet 
  > 
  > 
  >

---

From: Phil Roberts <[email-masked]>
Date: Tue, 17 Sep 2002 13:46:15 -0400

Will the IPR statement apply to the doc once extended mode
is separated into a separate draft?

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2002 1:26 PM
> To: Hesham Soliman (EAB); [email-masked]
> Hi Hesham,
> I wonder if we could get the chairs to ask the IESG for an 
> early ruling on the
> IPR statement for HMIP. It is rather unusual, and I would 
> rather that we not end
> up in a position like that which I believe occured in the 
> iSCSI WG, in which the
> chairs and WG proceeded forward on a draft for standards 
> track only to be told
> by the IESG at the end that the IPR was not acceptable.
> 
> This could considerably expedite bringing HMIP to standard.
> 
>             jak
> 
> ----- Original Message -----
> From: "Hesham Soliman (EAB)" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, September 17, 2002 9:38 AM
> Subject: [mobile-ip] HMIPv6-next steps
> 
> 
> > Hi all,
> >

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 17 Sep 2002 20:16:31 +0200

> is separated into a separate draft?

=> I believe so. I can double check that.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 17 Sep 2002 20:39:49 +0200

> This option does not have to be in the base specification, 
  > unless there is wider
  > agreement that this would be a better design.
  > If it is not in the base specification, then RA-based MAP 
  > advertisement should
  > be properly qualified as the advertisement technique so 
  > that other techniques
  > are allowed. We are prepared to work together on designing 
  > a MAP discovery
  > technique if there is broader interest in this possibility, 
  > either in a separate
  > draft or as a contribution to the base draft.

=> I think the draft already qualifies the current 
discovery and mentions that other maybe designed 
in future. So I see no problem with adding another
feature later for MAP discovery. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 18 Sep 2002 03:22:10 +0200

> I think having extended mode as an individual submission to 
  > keep it active would
  > be a fine idea.
  > 
  > There's an issue of whether it should be done in MIP or in 
  > NEMO. The discussions
  > in NEMO about how the mobile router would handle the care 
  > of address look alot
  > like extended mode, and it might make sense to combine 
  > them. On the other hand,
  > the major issue of extended mode for MIP is how to handle 
  > route optimization,
  > which won't be considered as a fixed design for a bit yet 
  > in NEMO. Perhaps we
  > could keep it in MIP and continue considering how to do RO, 
  > then if we figure
  > something out it might provide some input into NEMO.

=> That's correct. The need for extended mode is, to
a large extent not related to NEMO. In addition,
today's NEMO charter says that we will not initially
produce a solution for RO. There will be a study of 
the solution space that would hopefully lead to 
rechartering and eventially a solution. 

I think Greg has valid points on the need for 
extended mode in MIP as well. So keeping it 
as a separate draft in MIP is certainly one 
option. 

Having said that, we still have some security 
issues with basic mode that we need to work out, 
so it might be good to focus on this and hopefully
(as Greg mentioned) the extended mode solution will
follow, if not at the same time. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 18 Sep 2002 03:32:46 +0200

Thanks for the feedback!

  > I think that getting (Basic) HMIPv6 out ready for use
  > is very important, but would be reluctant to see
  > extended mode disappear from the WG completely.

=> Agreed.

  > Obviously of the NEMO applications of extended mode
  > are possible, but the improvements over basic
  > mode make it useful in  a mobile-ip context as well.

=> Agreed. This is the point I was hoping to
get through earlier.

  > I don't think that there will be too much work to
  > bring extended mode into conformance with MIPv6.
  > As I indicated in the thread of 5 september -
  > 'supporting multiple nodes behind one CoA CoTI/CoT',
  > limited modification is required to perform RR on
  > Extended Mode devices.

=> ok.

  > Is it an option to put a (largely unmodified) version
  > of the extended mode spec up as a draft soon, so that it
  > doesn't disappear out of the LMM debate?

=> Sure.

  > We could fix it up later as time allows.
  > Even an individual submission would be valuable.

=> Agreed.

Hesham

---

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 20 Sep 2002 00:36:35 -0400

Putting extended into a separate doc within MIP wg seems much the best thing
to me at this. It may well then be necessary to split part of the extended
mode features into a specific doc for NEMO and keep the main signalling and
forwarding features in MIP.

When you have updated the HMIP draft then I'd suggest that I document in a
separate draft the changes I would like to see to integrate Nested MIP
requirements (requirements + feature changes), or added as a HMIPv6
extension doc, and thereby avoid parallel terminology and solution work.

Hope that is ok with you,

Alan.

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: 18 September 2002 02:09
To: [email-masked]
Subject: [mobile-ip] HMIPv6-next steps

Hi all, 

Hesham

---

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 20 Sep 2002 01:52:35 -0400

Probably before we go into solution space we could do with detailing the
requirements and trade-offs wrt HMIPv6 as is (although everything you say
makes good sense for your implied requirements :-)

Cannot really do that till draft update appears although I am happy to write
my specific requirements out fairly quickly after that to cover the delta
between HMIPv6 and Nested MIP requirements.

Alan.

-----Original Message-----
From: Greg Daley [mailto:[email-masked]]
Sent: 20 September 2002 15:10
To: Alan O'Neill
Cc: 'James Kempf'; Hesham Soliman (EAB); [email-masked]
Subject: Re: [mobile-ip] HMIPv6-next steps

Hi Alan and James,

For an equivalency, we could allocate a site-scope local
multicast to which which the MAP sends advertisements.

This could be send with a finite multicast hop limit,
and maybe the MAP could indicate the original hoplimit
in the advertised option.

Therefore, each MAP may only send the multicast packets a
certain number of hops, and therefore their influence could be
controlled. Also, since the original number of hops is
available, MN's can determine the distance to the MAP
based on current hop limit (for map selection heuristics).

MAP options will not arrive together, so MN's may initially
select a non-optimal MAP, but a mechanism may be described
which allows later selection of a better MAP, if desired.

As a bonus, Access networks where no nodes are using HMIP
multicast discovery receive no advertisements ;)

Selection of HMIPv6 MAP could be performed based on the union
of HMIPv6 advertising techniques (Mcast/RA).  If the group
doesn't exist and no RA advertisements are received, then
fallback is MIPv6.

Greg,
Who's happy if he can use radvd to send map options.
(BSD-like License, source code available ;-)

Alan O'Neill wrote:
> James,
> 
> I also have some likely requirements here on controlled allocation of
MAPs.
> At the moment the MAP is selected by the MN based on routing metrics /
> precendence.
> 
> Hesham seems happy for that kind of work to continue outside the main spec
> so maybe we can combine these two aspects (adertisement and
> selection/allocation) together in a single piece of work down the line..
> 
> Alan.
> 
> Sent: 18 September 2002 03:27
> To: Behcet Sarikaya; Hesham Soliman (EAB)
> This is an issue that has come up in our discussions as well.
> 
> We are particularly interested in some way of doing MAP discovery that
does
> not
> involve detecting modified RAs. This could involve a custom built
> administratively scoped multicast discovery protocol, or possibly the use
of
> SLP
> or some other discovery protocol.
> 
> The reason for this is because we would like to maintain the option of
> deploying
> MIPv6 with standard IPv6 routers, and then deploy MAPs for location
privacy
> without requiring any modifications on the routers or configuration of
> router
> advertisements.
> 
> This option does not have to be in the base specification, unless there is
> wider
> If it is not in the base specification, then RA-based MAP advertisement
> should
> be properly qualified as the advertisement technique so that other
> techniques
> are allowed. We are prepared to work together on designing a MAP discovery
> technique if there is broader interest in this possibility, either in a
> separate
> From: "Behcet Sarikaya" <[email-masked]>
> To: "Hesham Soliman (EAB)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, September 17, 2002 10:07 AM
>>tried to point out in my draft on LMM architectures, the most important
>>one being how to detect domain changes, etc. The pointer to version 1 is

---

From: "Alan O'Neill" <[email-masked]>
Date: Sat, 21 Sep 2002 04:37:59 -0400

The final paragraph is more related to my interests James, the relationship
between MN movement and regional node selection..Hop count is not a good
enough arbitrator..

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: 21 September 2002 02:10
To: [email-masked]; Alan O'Neill
Cc: Hesham Soliman (EAB); [email-masked]
Subject: Re: [mobile-ip] HMIPv6-next steps

> doesn't exist and no RA advertisements are received, then

As a general rule, it is not a good idea to do service discovery by having
the
service advertise (routers being the exception because the advertisements
only
happen on a single link). The Novell discovery protocol often consumed 10%
of
the local network bandwidth because it had the services multicasting
periodic
advertisements.

A better idea is to have the host multicast to an administratively scoped
(RFC
2365, BCP23) multicast address when it wants to find the MAP. The network
operator controls the scopes, so different MAPs can appear in different
pieces
of the network topology.

Alternatively, we could use an anycast address, as is done with the Home
Agent.

One issue is whether there are particular attributes characterizing a MAP
other
than its location in the topology that might be of interest to a MN. The
location in the topology is controlled by the administratively scoped
multicast.
If so, then we may want to look at a more general service discovery
protocol,
like SLP. Otherwise, we may need to define a protocol to allow the MN to
sort
through the attributes. If not, then we can just use a multicast or anycast
address.

The other issue is how a host knows when it has moved outside the scope of a
MAP. Perhaps the returned MAP adverisement contains information (like
subnets
covered) which the host can use to determine when it has to look for a new
MAP.
This avoids the problem of the host having to constantly probe, or the MAP
to
constantly multicast.

            jak

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 23:49:45 +0200

> > This doesn't necessarily get us to a point where we can choose
  > > the best MAP though, if we rely on probes only when we enter
  > > a domain not covered by the previous MAP, we won't be able to
  > > adjust to a better MAP when we're in an access network where
  > > MAP coverage overlaps.
  > >
  > 
  > What is the requirement for overlaps?

=> Overlaps are needed for 2 reasons:
1. Redundancy: this would involve MAPs covering the same area
2. Early detection of movement: The MN would see that a new MAP
   appeared at the bordering router and register early with it. 

The draft already mentions this but we can add more text.

Hesham