Hello, thanks for the prompt and detailed response.
>>>>> On Sun, 02 Jun 2002 23:25:06 -0700,
>>>>> Charlie Perkins <[EMAIL PROTECTED]> said:
> What I thought is that the mobile-ip group should decide what makes
> sense, as far as support for mobility is concerned. Mandated behavior
> for all nodes clearly requires discussion in this group. We are now
> having discussion in this group. It would not make sense to have the
> discussion until the mobile-ip group knew what needed to be done.
> And, in fact, the level of specification (MUST or SHOULD) has not
> been decided in the mobile-ip group either. So, this means you are
> getting your wish.
Okay. I really hope this rule will be kept in future discussions.
(Of course, proposal related to mobile-ip will typically come from the
mobileip wg, including the ones that affect all nodes.)
>> In this sense I think it was an unfortunate thing to make the support
>> of home address option mandatory in the mobile ipv6 draft. It should
>> have been approved by the ipv6 (or ipngwg) wg (I don't remember if it
>> was though), and should have been documented in a basic specification
>> of IPv6 once approved.
> It never got to the point of going through Last Call, so it was never
> quite ready enough to introduce the discussion here.
Okay. I was actually concerned about arguments like:
>>>>> On Wed, 22 May 2002 08:53:08 -0700,
>>>>> "Charles E. Perkins" <[EMAIL PROTECTED]> said:
> That is under discussion. In fact, I strongly believe that EVERY
> IPv6 correspondent node MUST implement return routability procedures.
> Furthermore, every IPv6 node already MUST implement Home Address Option.
I understood this was a personal opinion, but I read this to mean that
1. the decision about Home Address Option was already done. it's a
MUST.
2. now that Home Address Option is a MUST, it should be quite natural
to mandate return routability (or the entire function of route
optimization) as well.
(though I may have misunderstood the nuance in the first place) if
this kind of logic is justified, we'll be able to make arbitrary
extensions that affect all nodes by a proposal in a draft written and
discussed within a particular group. I was afraid about this stroy.
But, I'm okay if the ipv6 wg (in this case) will discuss if an
extension mandating something to all nodes is acceptable, and the wg
can even start with rejecting former proposals which are MUST.
(here I'm just talking about the general procedure, rather than the
particular issue of Home Address Option).
> I think that everyone agrees that the behavior should be configurable,
> either dynamically or by administrative configuration.
Okay.
> What do you think about the points I tried to make a few days ago
> about general scalability and the likely proportion of future nodes
> that will be mobile nodes.
I respect your insight, but my honest feeling is that it was a guess.
We do not have actual results about the delay when communicating
without route optimization. We're (or I am) not sure about the real
rate of nomadic nodes *speaking mobile-ip* in the future Internet.
IMO, requiring a MUST (for all nodes) due to a performance issue needs
a concrete evidence like results of performance tests, not a guess.
We can say that a SHOULD means every implementation can be compliant
without supporting route optimization at the cost of efficiency in
mobile-ip environments. However, we can also say that a MUST means
any implementation can be faulted not to be compliant even if the
implementation was not expected to make frequent communication with
mobile-ip nodes and wanted to omit route optimization due to (e.g.)
very limited resources.
I recall the discussion about "minimum requirements" for low-cost
appliances or for 3G devices. The authors of the drafts proposed to
omit some features which are mandated in existing RFCs, due to limited
resources and usages. The result of the discussion was "we cannot
allow such non-compliant implementations that easily". Once we
mandate route optimization, the same situation may happen in the
future.
Since such low-cost devices will also be in a large part of the future
Internet (v6) (though some of such low-cost devices can act as a
frequent correspondent nodes), I don't think it a good idea to add
another restriction at this early stage. In theory, we can change
requirements described in RFCs if we find them inappropriate in the
future. However, the recent discussion about the low-cost devices
shows it will be very hard in practice.
>> Honestly, the argument for the MUST so far does not seem to me very
>> convincible - after all, mobile-ip (v4 or v6) nodes only occupy a very
>> small part in the current Internet.
> Likewise, nodes secured by IPv6 IPsec AH occupy only a small portion
> of the Internet. Do you apply the same argument to convince yourself
> that the IPsec mandate was a mistake?
No, because in this case it's an all-or-nothing choice; if we do not
implement IPsec, we cannot be secure (at least at the IP level). On
the other hand, even if we do not implement the route optimization, we
can still communicate with mobile nodes in some less-efficient manner.
Of course, one can say that the mobility case is also an
all-or-nothing choice, i.e. that "the less-efficient manner" means not
working. But, at least to me, the latter argument is not as clear as
the former - again, we do not have concrete results about the
performance.
Going back to the route optimization issue, I don't just get why we
cannot go with a SHOULD. Some implementors have already said that
they will implement the feature (even with a SHOULD). So, we'll at
least have an environment to test the effectiveness, interoperability,
performance (and whatever necessary) of the optimization to make a
further decision. If the deployment schedule is as you expected:
> Even if it's mandated, I doubt we would see interoperability tests before
> next year, and then implementation in products not before end of 2003.
then I think we can wait for results of the experiments, rather than
to make a strong requirement for all nodes at this stage.
(I won't make responses to other parts of your reply, because they
would almost be a repeat of the points above. If you feel it unfair,
please point it out).
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
