Subject: RE: [Mipshop] RE: Last Call Comments on draft-ietf-mishop-hmipv6- 00.txt

From: Soliman Hesham <[email-masked]>
Date: Wed, 19 Nov 2003 01:12:28 -0500

> The way I remember it, I originally (several years ago) 
 > objected to having
 > these flags because I thought they were too complex, and 
 > simply wanted the
 > MN to tunnel back to the MAP, but in the face a sustained 
 > email barrage from
 > one of the authors of the draft and lacking any support from other WG
 > members in helping me to fend off the barrage, I relented in 
 > order to spare
 > myself further DoS on my email reading and responding time. :-)

=> The P flag was added based on your request to hide the
operator's IP addresses. I'm happy to remove it if no
one objects. Doesn't look like anyone will. So the 
rest of the discussion is on the I and V flags.

 > In the interim, the effect on ingress filtering occured to 
 > me (as I've been
 > sensitized to security issues of late) so I raised the issue 
 > again recently
 > in Last Call. While I agreed with your response about it 
 > being possible to
 > configure the routers locally to pass the RCoA, because the 
 > MAP is in the
 > local administrative domain (unlike the HA), 

=> Ok, so we both agree on that. The scenario that was discussed
in the meeting cannot happen if the MN is able to detect movement 
and create a new LCoA. But anyway, with the P flag 
removed, this scenario will never happen.

 >     > => The Dist field is there to tell the MN how "far"
 > > the MAP is. There is only one level of hierarchy in HMIPv6,
 > > so the Dist doesn't say anything about levels of hierarchy.
 > > The purpose of this field is to aid the MN in selecting
 > > the right MAP. The knowledge that the MN should have in order
 > > to use this field is really link layer specific (i.e.
 > > speed for instance) so we couldn't put more info than
 > > that in the draft. I can add more text to explain this.
 > >
 > 
 > The issue is that there are no rules for how to set this 
 > field and therefore
 > there is no way decide what to select except for the two 
 > extremes. That is,
 > suppose in one network I have Dist values of 100, 40, 7, and 
 > 2. All the MN
 > really knows is that 100 is the furtherst and 2 is the 
 > least. The others are
 > essentially useless, since there is no metric defined on the 
 > numbers that
 > would let the MN decide which is better. Furthermore, the 
 > numbers can vary
 > between networks. Suppose in another network the values are 
 > 40 10 and 6. Is
 > the 40 value comparable?

=> The basic idea is that a fast moving MN will want
to pick a further MAP. However, since measuring the 
speed is link layer dependent we could not say more 
than that. The actual value is not that important. The
only requirement is that within the same admin domain, 
the interpretation of values is consistent. So when a 
MN moves to a new network, new values will not be compared
with old ones.

 > In fact, it might be useful to have a section that describes 
 > the order of
 > messaging to accomplish MAP handover, since it is major 
 > feature of HMIP
 > beyond simply using a local HA. With a local HA, there's no handover.

=> This was the idea for the appendix, but it currently doesn't
address inter-MAP handovers. Will add a new section on that.

Hesham

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Nov 2003 13:14:00 -0800

> MN moves to a new network, new values will not be compared

Suppose I'm not moving fast, not moving slow. How do I decide if I should
use 40 or 7, in my example where MAPs at 100, 40, 7 and 2 are advertised?
And, what's meant by fast? 100 kph could be fast in one operator's network,
whereas 30 might be fast in anothers.

Absent any metric on these numbers and criteria for judging, this seems like
an invitation for an interoperability problem.

            jak