Subject: [MEXT] Fwd: Comments on Section 9.0 (Mobility) - draft-ietf-6man-node-req-bis-05

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Aug 2010 08:26:43 -0700

Please review and comment on Mobility section, on the IPv6 Node Requirements document (draft-ietf-6man-node-req-bis-05). This is being discussed in 6man.

Sri

Begin forwarded message:

> From: Sri Gundavelli <[email-masked]>
> Date: August 20, 2010 8:22:00 AM PDT
> To: IPv6 WG Mailing List <[email-masked]>
> Subject: Comments on Section 9.0 (Mobility) - draft-ietf-6man-node-req-bis-05
> 
> Couple of comments on Section 9.0 (Mobility): draft-ietf-6man-node-req-bis-05
> 
> 1.) When Mobile IPv6 was designed, one important feature that made into the protocol is the support for Route Optimization. The ability for a mobile node to provide the information on the direct (non-anchor or non-triangular) path to a Correspondent Node. This was not possible in Mobile IPv4, as any change requirement to IPv4 did not make much sense. This is one feature of Mobile IPv6 that stands out. The semantics of RO, say Type-II RH, is part of the basic IPv6 feature. Most IPv6 stacks have support for these options and in most cases the RO procedure as well. Given this,  It is very important that the IPv6 Correspondent Node functionality is mandated on every IPv6 node. However, the Home Agent functionality on IPv6 routers, or the Mobile Node stack on a IPv6 node, can be optional, that is fine. But, its important that the end-points has natural RO support.
> 
> 2.) I'd additionally remove the comments around lack of deployment experience around the protocol. This comment applies to practically every IPv6 feature, SEND or other extensions.  In fact with Mobile IPv4 being a core mobility protocol in CDMA, we probably have bit more related experience on the node requirements from IPv6 node perspective.
> 
> 3.) Section 9.0 should be reviewed by MEXT, NETLMM and NETEXT working groups, so the node requirements with respect to IP Mobility are properly presented.
> 
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 23 Aug 2010 09:27:06 +0800

Hi Sri,

I don't understand your comments.

The semantics of RO, say Type-II RH, is part of the basic IPv6 feature. Most
IPv6 stacks have support for these options and in most cases the RO
procedure as well. 

I'm not sure about this point, Type-II RH is defined in RFC3775, why we say
it is a basic IPv6 feature?

And you said most IPv6 stacks have support for these options and RO
procedure, do you mean the stacks support transmitting these options or
accepting these options?

Your statement seems to me that most IPv6 stacks have support for Route
Optimization. But since Home Test Init Message and Home Test Message must be
forwarded by Home Agent, can we say that most IPv6 stacks have support for
both tunnel mode and route optimization mode?

Given this,  It is very important that the IPv6 Correspondent Node
functionality is mandated on every IPv6 node. 

Why CN functionality is mandated on every IPv6 node? This is a distinct
change.

Best Regards,

Xiangsong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri
Gundavelli
Sent: Friday, August 20, 2010 11:27 PM
To: [email-masked]
Subject: [MEXT] Fwd: Comments on Section 9.0 (Mobility) -
draft-ietf-6man-node-req-bis-05

Please review and comment on Mobility section, on the IPv6 Node Requirements
document (draft-ietf-6man-node-req-bis-05). This is being discussed in 6man.

Sri

Begin forwarded message:

Subject: Comments on Section 9.0 (Mobility) -
draft-ietf-6man-node-req-bis-05

Couple of comments on Section 9.0 (Mobility):
draft-ietf-6man-node-req-bis-05

1.) When Mobile IPv6 was designed, one important feature that made into the
protocol is the support for Route Optimization. The ability for a mobile
node to provide the information on the direct (non-anchor or non-triangular)
path to a Correspondent Node. This was not possible in Mobile IPv4, as any
change requirement to IPv4 did not make much sense. This is one feature of
Mobile IPv6 that stands out. The semantics of RO, say Type-II RH, is part of
the basic IPv6 feature. Most IPv6 stacks have support for these options and
in most cases the RO procedure as well. Given this,  It is very important
that the IPv6 Correspondent Node functionality is mandated on every IPv6
node. However, the Home Agent functionality on IPv6 routers, or the Mobile
Node stack on a IPv6 node, can be optional, that is fine. But, its important
that the end-points has natural RO support.

2.) I'd additionally remove the comments around lack of deployment
experience around the protocol. This comment applies to practically every
IPv6 feature, SEND or other extensions.  In fact with Mobile IPv4 being a
core mobility protocol in CDMA, we probably have bit more related experience
on the node requirements from IPv6 node perspective.

3.) Section 9.0 should be reviewed by MEXT, NETLMM and NETEXT working
groups, so the node requirements with respect to IP Mobility are properly
presented.

Regards
Sri