Subject: [multimob] Adoption of HO drafts incl. draft-schmidt-multimob-fmipv6-pfmipv6-multicast

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 31 Jul 2012 15:31:35 -0500

Hi all,
There is an issue that we missed in Monday Multimob session that I
would like to bring to attention:

We did have, apart from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast, several other
multicast handover solution drafts such as:
http://tools.ietf.org/html/draft-vonhugo-multimob-cxtp-extension-01

http://tools.ietf.org/html/draft-hui-multimob-fast-handover-04

These are the documents that are still active. There could be others
that are no longer active.

If we decide to accept more than one handover solution then we
probably need to consider all of them for possible WG adoption.

What do you think?

Regards,

Behcet

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 31 Jul 2012 22:35:18 +0100

Hi Behcet,

Could you let me know the reason why we need to consider 
this?

Seil

On Tue, 31 Jul 2012 15:31:35 -0500
  Behcet Sarikaya <[email-masked]> wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 31 Jul 2012 15:02:41 -0700

Hi Behcet, hi all,

please see inline.

> http://tools.ietf.org/html/draft-vonhugo-multimob-cxtp-extension-01

This draft basically uses the context transfer protocol (RFC4067) to 
carry multicast state between ARs/MAGs. No full handover operations have 
been specified.
At the unicast side, RFC4067 is a predecessor of the more advanced Fast 
Handover Protocols does not apply to unicast handover management.... IMO 
it does not make much sense to consider this rather elementary approach 
any further.

> http://tools.ietf.org/html/draft-hui-multimob-fast-handover-04

This draft is - if you want so - a competitor to 
draft-schmidt-multimob-fmipv6-pfmipv6-multicast, but has never been 
worked out  (as have several other attempts in the past). If this 
document was to be advanced, it had to rewrite (or copy ??) 80 % of our 
draft, which is not a proper way to treat authorship.

> probably need to consider all of them for possible WG adoption.

I don't understand your thinking here: it is perfectly normal that there 
are competing approaches and the idea of the IETF discussion is to have 
the best solution win. From the performance side, and from protocol 
systematics (cooperation with unicast), 
draft-schmidt-multimob-fmipv6-pfmipv6-multicast is clearly the best 
solution for fast handover operations - this comparison includes the 
adopted draft "fast handover from transient binding".

Cheers,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 31 Jul 2012 22:01:32 -0700 (PDT)

Thomas,

> carry multicast state between ARs/MAGs. No full handover operations
> have been specified.

It is because this draft inherits the basic operation from rfc4067 and
hence no need to repeat to write it. The main aim of this draft is to
define the message format for multicast context transfer with CXTP.
Of course, if something is missing and required to clarify in the
document, the authors will try to improve the document quality, I
believe.

> At the unicast side, RFC4067 is a predecessor of the more advanced
> Fast Handover Protocols does not apply to unicast handover
> management.... IMO it does not make much sense to consider this rather
> elementary approach any further.
> 
> document was to be advanced, it had to rewrite (or copy ??) 80 % of
> our draft, which is not a proper way to treat authorship.

The -00 version of draft-hui was published on June 29, 2009.
Your -00 draft was published on March 01, 2010.
(I just tell the fact.)

> I don't understand your thinking here: it is perfectly normal that
> there are competing approaches and the idea of the IETF discussion is
> to have the best solution win. From the performance side, and from
> protocol systematics (cooperation with unicast),

If only one HO document is needed, then since this WG has already been
working for SIAL proposal, other documents (including yours) related
to HO are not needed, are they?

Furthermore I don't think all mobile operators in the world adpot only
FPMIPv6 as their business. So, if other idea is useful and technically
correct, documenting it is reasonable.

This is just my feeling.

Regards,
--
Hitoshi Asaeda