headers
Qin Wu | 2 Mar 2009 09:20
Favicon

Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

Hi,Ahmad:
please see inline.
----- Original Message ----- 
From: "Ahmad Muhanna" <amuhanna <at> nortel.com>
To: "Qin Wu" <sunseawq <at> huawei.com>
Cc: <mext <at> ietf.org>
Sent: Sunday, March 01, 2009 7:12 AM
Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

Hi, Qin,
Please see inline.

>  
> 
> [Ahmad]
> I am not sure if we can achieve everything in the revocation by using
> de-registration. BRI gives more information than what can be 
> carried in
> de-registration. Please remember, MAG can send a BRI in the case of
> multiple bindings revocation already. Is what you are saying: 
> we need to
> specify how BRI can be used for revocation from the MAG in all cases?
> If not and you are interested in PBU as a de-registration, 
> then probably
> what in PMIP6 is good enough.
> [Qin]Since the MAG can send BRI instead of PBU, may I suggest 
> to specify how BRI can be used for revocation from the MAG?

[Ahmad]
Personally, I believe that is a good idea. Especially, the MAG already
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ahmad Muhanna | 2 Mar 2009 14:03
Favicon

Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

Hi Qin,

> 
> [Ahmad]
> Personally, I believe that is a good idea. Especially, the MAG already
> uses BRI to send a Global BRI. However, if I recall, there was some
> opposition to this early on and that why we did not include it.
> 
> In order to add this to the draft, we need enough people to 
> support that
> on the ml.
>  [Qin]: In mip4 scenario, binding revocation could be 
> supported from fa to ha, or by generic notifcation draft. Am I right?

[Ahmad]
This comparison is NOT valid here. Just as a note, generic notification
message is NOT used for revocation.

> So I would like to support extending MAG to send BRI message 
> for binding revocation in pmip6 scenario.
[Ahmad]
As I said, that need support of the wg before adding it.

> Also I wonder whether  MN sending BRI message for binding 
> revocation is allowed in the draft-mext -binding-revocation-03.
> 
> 
> > Regards,
> > Ahmad
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giaretta, Gerardo | 2 Mar 2009 21:56

Re: [MEXT] Proposed RFC editor change for DSMIPv6

Hi Hesham,

The text is fine.

Thanks
Gerardo

> -----Original Message-----
> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On Behalf Of Hesham
> Soliman
> Sent: Saturday, February 28, 2009 12:00 AM
> To: mext <at> ietf.org
> Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil
> Subject: [MEXT] Proposed RFC editor change for DSMIPv6
> 
> Folks,
> 
> I had a private conversation with Raj where he suggested that the HA
> discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be
> done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can
> be used to provide the IPv4 address for the HA.
> 
> We discussed the fact that this option would not tell the MN if the HA is
> dual stack or if it supports DSMIPv6 at all. So it will be a trial and error
> type discovery (unlike the current use of DNS or DHCPv6).
> 
> Raj Proposed the text below. One might also want to consider running DHCPv6
> on top of IPv4, which IMO is a clearer option for this case.
> 
> Please let us know if you agree with this text, I'm cc'ing Jari and Pasi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijay Devarapalli | 2 Mar 2009 22:52
Favicon

Re: [MEXT] Proposed RFC editor change for DSMIPv6

Hi Hesham and others,

I don't think we should do this. The existing DHCPv4 option 68 clearly
indicates that it is the Mobile IPv4 home agent information that is
being conveyed. Using that for discovering the DS-MIPv6 home agent would
be a hack. Moreover, this option will not be able to convey the IPv6
address of the DS-MIPv6 home agent when the mobile node boots up on the
IPv4 access network.

Why don't we have a separate short spec that defines a new DHCPv4 option
for discovering a DS-MIPv6 home agent information when the mobile node
is attached to an IPv4 access network? It shouldn't take too long to get
this spec done. 

Vijay

> -----Original Message-----
> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On 
> Behalf Of Hesham Soliman
> Sent: Saturday, February 28, 2009 12:00 AM
> To: mext <at> ietf.org
> Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil
> Subject: [MEXT] Proposed RFC editor change for DSMIPv6
> 
> Folks, 
> 
> I had a private conversation with Raj where he suggested that the HA
> discovery for DSMIPv6, when a mobile node is in an IPv4-only 
> network, can be
> done using DHCPv4. Raj referred to a DHCP option designed for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Basavaraj.Patil | 2 Mar 2009 22:58
Picon

Re: [MEXT] Proposed RFC editor change for DSMIPv6


Hi Vijay,

Do you see a problem with using the existing DHCPv4 option for indicating
the IPv4 address of the DSMIP6 HA?

Ideally we should define a new DHCPv4 option which carries the v4 and v6
addresses of the DSMIP6 HA to the MN when booting up in an IPv4 only
network. As Hesham mentioned, the MN will discover via trial/error the type
of HA that the v4 address is associated with.
While this can be done in the DHC WG in parallel if the WG decides to do so,
I see no harm in including the proposed text.

-Raj

On 3/2/09 3:52 PM, "ext Vijay Devarapalli" <vijay <at> wichorus.com> wrote:

> Hi Hesham and others,
> 
> I don't think we should do this. The existing DHCPv4 option 68 clearly
> indicates that it is the Mobile IPv4 home agent information that is
> being conveyed. Using that for discovering the DS-MIPv6 home agent would
> be a hack. Moreover, this option will not be able to convey the IPv6
> address of the DS-MIPv6 home agent when the mobile node boots up on the
> IPv4 access network.
> 
> Why don't we have a separate short spec that defines a new DHCPv4 option
> for discovering a DS-MIPv6 home agent information when the mobile node
> is attached to an IPv4 access network? It shouldn't take too long to get
> this spec done.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijay Devarapalli | 2 Mar 2009 23:02
Favicon

Re: [MEXT] Proposed RFC editor change for DSMIPv6

Hi Raj,

Basavaraj.Patil <at> nokia.com wrote:
> Hi Vijay,
> 
> Do you see a problem with using the existing DHCPv4 option for indicating
> the IPv4 address of the DSMIP6 HA?

It can be made to work, but it is not exactly an elegant solution.

> Ideally we should define a new DHCPv4 option which carries the v4 and v6
> addresses of the DSMIP6 HA to the MN when booting up in an IPv4 only
> network. As Hesham mentioned, the MN will discover via trial/error the type
> of HA that the v4 address is associated with.
> While this can be done in the DHC WG in parallel if the WG decides to do so,
> I see no harm in including the proposed text.

This I disagree with. You would end up with two solutions, one in the 
DS-MIPv6 document that says you can use option 68 to discover a DS-MIPv6 
home agent and the other in the DHC WG that defines a new option. We 
should decide now itself, whether we want to use option 68 or a new option.

Vijay

> 
> -Raj
> 
> 
> On 3/2/09 3:52 PM, "ext Vijay Devarapalli" <vijay <at> wichorus.com> wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Xia | 2 Mar 2009 23:23
Favicon

Re: [MEXT] Proposed RFC editor change for DSMIPv6

Hi All

I think we should define new DHCPv4 option.

Please check the pointer
http://www.ietf.org/mail-archive/web/mext/current/msg01375.html
which described the discussion the requirement for
DHCPv4 option when DHCPv6 ones were standardized.

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <vijay <at> wichorus.com>
To: <Basavaraj.Patil <at> nokia.com>
Cc: <Pasi.Eronen <at> nokia.com>; <mext <at> ietf.org>; <jari.arkko <at> piuha.net>
Sent: Monday, March 02, 2009 4:02 PM
Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6

> Hi Raj,
>
> Basavaraj.Patil <at> nokia.com wrote:
>> Hi Vijay,
>>
>> Do you see a problem with using the existing DHCPv4 option for indicating
>> the IPv4 address of the DSMIP6 HA?
>
> It can be made to work, but it is not exactly an elegant solution.
>
>> Ideally we should define a new DHCPv4 option which carries the v4 and v6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Desire Oulai | 3 Mar 2009 04:49
Picon
Favicon

[MEXT] FW: New Version Notification for draft-oulai-mext-dsmip-v4ro-ps-00

Hi all,

  We have submitted a problem statement draft on route optimization for
DSMIP. This document looks at the different scenarios where IPv4 route
optimization is desirable and highlights some problems. 

Thanks for you comments.

Regards

Desire

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org] 
> Sent: March 2, 2009 10:45 PM
> To: Desire Oulai
> Cc: Suresh Krishnan; hesham <at> elevatemobile.com
> Subject: New Version Notification for 
> draft-oulai-mext-dsmip-v4ro-ps-00 
> 
> 
> A new version of I-D, draft-oulai-mext-dsmip-v4ro-ps-00.txt 
> has been successfuly submitted by Desire Oulai and posted to 
> the IETF repository.
> 
> Filename:	 draft-oulai-mext-dsmip-v4ro-ps
> Revision:	 00
> Title:		 Problem Statement for Route 
> Optimization in dual stack environments
> Creation_date:	 2009-03-03
(Continue reading)

Permalink | Reply | 0 comments |
headers
Desire Oulai | 3 Mar 2009 04:52
Picon
Favicon

[MEXT] FW: New Version Notification for draft-oulai-mext-dsmip-ro-00

Hi all,

 We have submitted a solution draft for the DSMIP route optimization. It
tackles the return routability procedure for an IPv4 Home address and an
IPv4 CareOf address. We try to reuse as much as possible the base
soluton existing for MIPv6. 

Thanks for your comments.

Regards

Desire

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org] 
> Sent: March 2, 2009 10:48 PM
> To: Desire Oulai
> Cc: Suresh Krishnan; hesham <at> elevatemobile.com
> Subject: New Version Notification for draft-oulai-mext-dsmip-ro-00 
> 
> 
> A new version of I-D, draft-oulai-mext-dsmip-ro-00.txt has 
> been successfuly submitted by Desire Oulai and posted to the 
> IETF repository.
> 
> Filename:	 draft-oulai-mext-dsmip-ro
> Revision:	 00
> Title:		 DSMIPv6 Route Optimization
> Creation_date:	 2009-03-03
> WG ID:		 Independent Submission
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 3 Mar 2009 11:24

Re: [MEXT] Proposed RFC editor change for DSMIPv6

I agree with Vijay and we should not do this.

I'm not sure if I'm missing something, but 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-17.txt carries 
IPv4 addresses of Mobile IPv6 home agents as well. Why isn't that 
sufficient?

Jari

Hesham Soliman wrote:
> Folks, 
>
> I had a private conversation with Raj where he suggested that the HA
> discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be
> done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can
> be used to provide the IPv4 address for the HA.
>
> We discussed the fact that this option would not tell the MN if the HA is
> dual stack or if it supports DSMIPv6 at all. So it will be a trial and error
> type discovery (unlike the current use of DNS or DHCPv6).
>
> Raj Proposed the text below. One might also want to consider running DHCPv6
> on top of IPv4, which IMO is a clearer option for this case.
>
> Please let us know if you agree with this text, I'm cc'ing Jari and Pasi
> because Pasi made a comment earlier on this section. Since the draft has
> already been reviewed by the IESG, I suggest that if the WG agrees with this
> text, it should be added to the RFC editor notes.
>
> Proposed text to be added:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane