Vijay Devarapalli | 2 Sep 19:25 2008

Adoption of draft-yokota-mipshop-pfmipv6 as a WG document

Hello,

At the MIPSHOP WG meeting at the last IETF, there was consensus to adopt
draft-yokota-mipshop-pfmipv6 as a WG document. We would like to confirm
that consensus on the mailing list. 

Please respond by September 16, if you support or do not support
adopting the document as a WG document. If you have already expressed
your opinion in the WG meeting, there is no need to send an email on
this.

Vijay
Charles E. Perkins | 3 Sep 21:46 2008

Re: Adoption of draft-yokota-mipshop-pfmipv6 as a WG document

Hello folks,

It seems like a good idea for this document to become
a working group draft.  However, I am not in favor
of the Mobility Header formulation for the signaling.
I think it would be better to maintain as close as
possible compatibility with the FMIP formats.

Regards,
Charlie P.

> Hello,
>
> At the MIPSHOP WG meeting at the last IETF, there was consensus to adopt
> draft-yokota-mipshop-pfmipv6 as a WG document. We would like to confirm
> that consensus on the mailing list. 
>
> Please respond by September 16, if you support or do not support
> adopting the document as a WG document. If you have already expressed
> your opinion in the WG meeting, there is no need to send an email on
> this.
>
> Vijay
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
>   
>
(Continue reading)

Internet-Drafts | 4 Sep 11:15 2008
Picon

I-D Action:draft-ietf-mipshop-mstp-solution-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working
Group of the IETF.

	Title           : Mobility Services Framework Design (MSFD)
	Author(s)       : T. Melia, et al.
	Filename        : draft-ietf-mipshop-mstp-solution-06.txt
	Pages           : 23
	Date            : 2008-09-04

This document describes a mobility services framework design (MSFD)
for the IEEE 802.21 Media Independent Handover (MIH) protocol that
addresses identified issues associated with the transport of MIH
messages.  The document also describes mechanisms for mobility
service (MoS) discovery and transport layer mechanisms for the
reliable delivery of MIH messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
(Continue reading)

Jari Arkko | 4 Sep 14:23 2008
Picon

re-review of mstp-solution


Thanks for the new version. I have looked at it and the previous AD 
review, and I'm in general satisfied with the result. The draft has been 
sent for Last Call.

Jari
The IESG | 4 Sep 15:48 2008
Picon

Last Call: draft-ietf-mipshop-mstp-solution (Mobility Services Framework Design (MSFD)) to Proposed Standard

The IESG has received a request from the Mobility for IP: Performance, 
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:

- 'Mobility Services Framework Design (MSFD) '
   <draft-ietf-mipshop-mstp-solution-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2008-09-18. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16802&rfc_flag=0
Hidetoshi Yokota | 4 Sep 16:19 2008
Picon

Re: Adoption of draft-yokota-mipshop-pfmipv6 as a WG document

Hi Charlie,

Thanks for your support and comment.
I see your point. It is a natural thought to follow the message format
defined in FMIPv6. The authors, however, received several requirements
from other sources and found that there are some rationales for using
the MH format.

* Since all the information handled by PFMIPv6 is related to the PMIPv6
operation and PMIPv6 uses the MH format, it is easier for the MAG to
handle only the MH than inspecting both headers.

* Many routers are configured to drop ICMPv6 packets for security
reason, so it would be easier to write a filter if PFMIPv6 uses the MH
format rather than inspecting the Type field of ICMPv6.

* Some people don't think using ICMP is the right way to convey
important messages that PFMIPv6 and PMIPv6 handle.

* Also, 3GPP2, which adopted this draft for their standards, prefers the
MH format. It's also good to listen to other SDOs and industry needs.

Note that none of the above completely precludes the use of ICMPv6. If
it is allowed to express my opinion, both are ok, although it would be
good to put priority on either one of those.

Regards,
--

-- 
Hidetoshi

(Continue reading)

Vijay Devarapalli | 4 Sep 19:10 2008

Re: Adoption of draft-yokota-mipshop-pfmipv6 as aWG document

Hello, 

> * Many routers are configured to drop ICMPv6 packets for security
> reason, so it would be easier to write a filter if PFMIPv6 uses the MH
> format rather than inspecting the Type field of ICMPv6.

We are not talking about a regular router here. It is a PMIPv6 MAG that
is processing these HI and HACK messages.

> * Some people don't think using ICMP is the right way to convey
> important messages that PFMIPv6 and PMIPv6 handle.

Hmm.. We have used ICMPv6 messages quite a bit for mobility protocols in
the IETF. For example, DHAAD messages, Mobile Prefix
solicitations/Advertisements for MIPv6, HI and HACK in FMIPv6 [RFC
5268], Context Transfer protocol messages [RFC 4067], etc..

> * Also, 3GPP2, which adopted this draft for their standards, 
> prefers the
> MH format. It's also good to listen to other SDOs and industry needs.
> 
> Note that none of the above completely precludes the use of ICMPv6. If
> it is allowed to express my opinion, both are ok, although it would be
> good to put priority on either one of those.

We have to pick between the MH-based and ICMPv6-based HI and HACK
messages. Specifying both only causes confusion and IOT problems. 

Vijay
(Continue reading)

Koodli, Rajeev | 4 Sep 19:35 2008

Re: Adoption of draft-yokota-mipshop-pfmipv6 asaWG document


Hi Vijay,

Even though we could argue that ICMP is sufficient, I think there is a
case for MH here. As Yokota-san pointed out, PMIP deployments, where
this protocol is expected to be used, do use MH and having the same
format for PFMIP messages makes sense. So, I would say we need to
support MH type based on the anticipated deployment considerations. What
this means is getting Type definitions, the message format and
processing is exactly the same as in RFC 5268.

See more below..

> We are not talking about a regular router here. It is a PMIPv6 MAG
that
> is processing these HI and HACK messages.

[RKo:>] Nevertheless, deployments could argue that they should not be
forced to make this choice: They are okay if we define both ICMP and MH.
Looks like you are arguing that we have to have only one type. More on
this below..

> Hmm.. We have used ICMPv6 messages quite a bit for mobility protocols
in
> the IETF. For example, DHAAD messages, Mobile Prefix
> solicitations/Advertisements for MIPv6, HI and HACK in FMIPv6 [RFC
> 5268], Context Transfer protocol messages [RFC 4067], etc..

[RKo:>] Right. But we don't have any deployment experience say in an
operator network, do we? (Granted PMIP is not yet deployed, but the
(Continue reading)

Vijay Devarapalli | 4 Sep 19:45 2008

Re: Adoption of draft-yokota-mipshop-pfmipv6 asaWG document

Hi Rajeev,

I was specifically responding to a couple of arguments in Yokota-san's
email. One was about routers not processing ICMPv6 messages and the
second was about ICMPv6 message being not suited for mobility signaling.
I don't think either of these two arguments are valid.  

The rest of the arguments presented by Yokota-san might be valid. We
need to discuss those on the mailing list. 

Without the working group chair hat on, I don't think we should specify
additional messages just because someone prefers MH-based HI and HACK
messages. This includes 3GPP2 as an SDO. There have to be good reasons
for specifying these new messages.

Vijay

> -----Original Message-----
> From: Koodli, Rajeev [mailto:rkoodli <at> starentnetworks.com] 
> Sent: Thursday, September 04, 2008 10:36 AM
> To: Vijay Devarapalli; Hidetoshi Yokota; Charles E. Perkins
> Cc: mipshop <at> ietf.org; Jari Arkko
> Subject: RE: [Mipshop] Adoption of 
> draft-yokota-mipshop-pfmipv6 asaWG document
> 
> 
> Hi Vijay,
> 
> Even though we could argue that ICMP is sufficient, I think there is a
> case for MH here. As Yokota-san pointed out, PMIP deployments, where
(Continue reading)

Koodli, Rajeev | 4 Sep 20:05 2008

Re: Adoption of draft-yokota-mipshop-pfmipv6 asaWG document


Hi,

> I was specifically responding to a couple of arguments in Yokota-san's
> email. One was about routers not processing ICMPv6 messages and the
> second was about ICMPv6 message being not suited for mobility
signaling.
> I don't think either of these two arguments are valid.

[RKo:>] I do not see any deployment today where the DHAAD, Mobile Prefix
Sol/Adv, 5268 are being used. So, whereas we have defined them, we don't
have any feedback. As I said, where PMIP is being envisioned, I can see
why those deployments favor MH as opposed to ICMP.

> 
> The rest of the arguments presented by Yokota-san might be valid. We
> need to discuss those on the mailing list.

[RKo:>] We are doing that already :-)

> 
> Without the working group chair hat on, I don't think we should
specify
> additional messages just because someone prefers MH-based HI and HACK
> messages. This includes 3GPP2 as an SDO. There have to be good reasons
> for specifying these new messages.

[RKo:>] Does a deployment count? I hope it does. It used to be that we
used to listen to such things..

(Continue reading)


Gmane