Hello folks,

JINMEI Tatuya / 神明達哉 wrote:

> >>>>> On Thu, 30 May 2002 16:43:50 -0700,
> >>>>> Bob Hinden <[EMAIL PROTECTED]> said:
>
> > Independent of how this is resolved, I think the best place to define the
> > route optimization implementation requirements for all IPv6 nodes is in the
> > IPv6 Node Requirements document.  I don't think it should be in the Mobile
> > IPv6 specification because at a minimum implementers not planning to
> > implement Mobile IPv6 might not see it.  There is a design team effort
> > underway to produce an IPv6 Node Requirements draft and I think they should
> > have an -00 version out soon for w.g. review and comments.  This discussion
> > is important input into this document.
>
> I fully agree.  One of the most unfortunate things about the
> correspondent node discussion is that it has been discussed only
> within the mobileip wg.  It was reasonable when the support of mobile
> IP in correspondent nodes was optional.  However, I don't think it
> makes sense to decide something is mandatory for all nodes within a
> single group that has a very specific goal (mobile IPv6 in this case).

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.

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

> As for SHOULD vs MUST: as other guys pointed out, it depends on how
> the requirement solves a common situation and how the situation is
> critical.  Since the MUST affects all IPv6 nodes, the argument for the
> MUST basically must convince all IPv6 implementors, including
> OS/server vendors, router vendors, and even home appliance vendors.
> Additionally, if the requirement is not configurable (i.e. there is no
> knob to turn it off), the argument must also convince all IPv6
> operators such as ISPs and (possibly) cellular phone companies.

I think that everyone agrees that the behavior should be configurable,
either dynamically or by administrative configuration.

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.

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


>  It may be true that more and more
> "nomadic" nodes will come in the near future, where "nomadic" means
> the node moves from a link to another link while working, but I'm not
> fully convinced that all such "nomadic" nodes are speaking mobile IP.
> I'm also not sure how many (correspondent-only) nodes will need to
> communicate with mobile-IP nodes in the depicted by mobileip-ers.

A correspondent node CAN be a mobile node or not.  The point is
not to make a difference.  And, you are right that maybe not all such
nomadic nodes will use Mobile IP, but I think there is reasonable
expectation that they will, and results we have so far indicate that the
performance is good and the protocol operates as expected.  This will
be augmented as soon as is reasonable to expect by additional experience
with the return routability protocol.

> Please note, however, that I'm not necessarily making an objection to
> mobile-IP (v4 or v6) itself.  I'm just saying the MUST is too strong,
> considering the current situation and the uncertainty about the
> future.  With the fact that mobile IP is one of possible (though
> perhaps likeliest) solutions to support nomadic nodes, I believe it is
> better to make effects to other nodes as small as possible in order to
> deploy mobile IP itself.  So, I must vote for the SHOULD (or even
> MAY).  Even with the MUST, I can imagine that IPv6 stack implementors
> who are not convinced will ignore the requirement.  The result will be
> a certain amount of "non-compliant" implementations and loss of
> interoperability.  Even with the SHOULD, the implementors will
> implement the feature if communicating with mobile-IP nodes using the
> route optimization becomes attractive enough, while keeping the
> minimum interoperability.  I don't just get why we cannot go with this
> path.

The reason for mandating the binding management messages, is just
as I have stated it already a few days ago.  It makes a very noticeable
difference in performance when traffic has to be tunneled back and
forth through a home agent in a possibly quite distant network.  This
would be bad for many applications, especially those with various
delay bounds.  Did you look at my previous note on this, or should I
repeat the discussion?

>
> But what if it
> requires 1,000,000 lines in draft-mobileip-ipv6-99?

I'm sure you are kidding.  There won't be any such draft, and
it won't take drastic amounts of code.

>
> Can we still
> allow the requirement just because it is the "route optimization"
> which is a MUST?  mobileip-ers may want to say that the
> standardization will soon be done, but I've been seeing the same
> phrase for a few years and cannot be that optimistic (e.g. please do
> not forget that the notion of the "return routability" is very new.
> how can we be 100% sure that it's stable and will not change?).

Indeed, return routability is new.  I have myself hoped that we would
be done, and the original expectation is that the IPsec group would
provide something useful for key establishment.  When that did not
happen, we were eventually told that we didn't have the luxury of
waiting for someone else to do it.

Furthermore, if we mandate the return routability tests, and we never
get to Proposed Standard, then I reckon people are not going to be
very motivated to implement the specification.

The point is that if a node is going to support the Mobile IPv6
specification, it has to do the route optimization feature.  If IPv6
nodes don't need to support mobility (contrary to the mandate of the
original IPv6 directorate), then that needs to be laid out.  If IPv6
nodes are going to conform to the original mandate, then this is how
they would do so.  If we screwed up and the Return Routability test
isn't good, then IETF last call is supposed to catch that.  My opinion
is that it is pretty good, and I hope that after looking it over you will
think so too.  For the rest of the policy decisions, I can't add much.

>  Even
> if the next revision of the draft passes a wg last call, we'll still
> have a review period by the IESG, which is getting longer and longer
> nowadays.  So, we can only discuss if it is reasonable to make
> "section xx of draft-yy-zz" mandatory for all IPv6 nodes.  This, of
> course, does not make sense much, which is another reason why the
> SHOULD (or MAY) is better.

According to this logic, all mandates are from now on impossible
for IPv6 nodes.

MAY is a disaster for mobility, at least from the point of view of
Mobile IPv6.

> In summary:
>
> - if we're going to make something mandatory for all IPv6 nodes, it
>   must be discussed in the ipv6 wg.

We are having the discussion.

> - (IMO) we cannot go with the MUST, considering the current situation
>   and some possible scenarios in the future.  We should delay the
>   decision, or should go with a SHOULD or a MAY.

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.
How much longer shall we delay?

> - it does not make sense just to say "the route optimization is
>   mandatory."  we should be more specific.

Specifically, Return Routability messages (HoTI, CoTI, HoT, CoT),
Home Address Option, and Binding Update.

Regards,
Charlie P.


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

Reply via email to