Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt

From: <[email-masked]>
Date: Sun, 4 Nov 2012 20:20:35 +0000

Hi all,

I think that the draft is in a good shape, but I have some comments. It is not clear to me which requirements need to be fulfilled by the provided solution in order to support the so called PMIPv6 multicast handover optimization. 
It might be useful to first describe the PMIPv6 multicast handover optimization requirements that need to be fulfilled  before describing the solution. The draft could then also describe how the provided solution supports a given requirement.

Best regards,
Georgios Karagiannis

________________________________________
Van: [email-masked] [[email-masked]] namens LUIS MIGUEL CONTRERAS MURILLO [[email-masked]]
Verzonden: dinsdag 23 oktober 2012 21:09
To: [email-masked]
Onderwerp: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt

Hi all,

Yesterday we submitted a new version of the WG document "draft-ietf-multimob-fast-handover", addressing received comments and pending sections.

Additional comments are welcome.

Best regards,

Luis

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de [email-masked]
Enviado el: lunes, 22 de octubre de 2012 20:07
Para: [email-masked]
CC: [email-masked]
Asunto: [multimob] I-D Action: draft-ietf-multimob-fast-handover-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multicast Mobility Working Group of the IETF.

        Title           : PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)
        Author(s)       : Luis M. Contreras
                          Carlos J. Bernardos
                          Ignacio Soto
        Filename        : draft-ietf-multimob-fast-handover-03.txt
        Pages           : 42
        Date            : 2012-10-22

Abstract:
   This document specifies a multicast handover optimization mechanism
   for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic
   to mobile nodes after handovers.  The mechanism is based on speeding
   up the acquisition of mobile nodes' multicast context by the mobile
   access gateways.  To do that, extensions to the current Proxy Mobile
   IPv6 protocol are proposed.  These extensions are not only applicable
   to the base solution for multicast support in Proxy Mobile IPv6, but
   they can also be applied to other solutions being developed to avoid
   the tunnel convergence problem.  Furthermore, they are also
   independent of the role played by the mobile access gateway within
   the multicast network (either acting as multicast listener discovery
   proxy or multicast router).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fast-handover-03

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

_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 05 Nov 2012 17:28:40 -0500

Hi Luis,

I was just flying over the rams/sial draft and saw my previous comments 
untreated.

This was the transient binding below ... and IPv4 treatment ... and some 
more details I had commented about 10 - 15 months ago, but cannot 
quickly find my mail. Please have a look.

So I guess you wanted to say "*partially* addressing received comments"

Cheers,

Thomas

-------- Original Message --------
Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding
Date: Mon, 30 Jul 2012 14:36:25 -0700
From: Thomas C. Schmidt <[email-masked]>
To: [email-masked] <[email-masked]>

Hi,

as discussed today in the meeting, the following question was raised:

draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to
nMAG - which in concept corresponds to the *Transient*Binding* in
unicast RFC 6058 http://tools.ietf.org/html/rfc6058.

draft-ietf-multimob-fast-handover does not even reference RFC 6058 ...
but probably should closely stick to the unicast solution.

So the question is about protocol systematics: Do we want unicast and
multicast protocol operations remain incompatible?

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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Nov 2012 00:13:28 +0100

Hi Thomas,

> quickly find my mail. Please have a look.

Regarding the transient binding, I thought Marco already commented on
that. I'm just pasting below what he said:

"Just a side note: As there was already some confusion during Vancouver
meeting and the reference to the transient binding extensions (RFC6058)
still shows up repeatedly, let me clarify one thing:

PFMIP6 and Transient Binding address different use cases, they
have been specified to address different problem spaces. It's 
not appropriate to refer to these two unicast protocol extensions
in the multicast space [...]"

Probably Luis can add on top of that.

> So I guess you wanted to say "*partially* addressing received comments"

Regarding the other comments you mentioned, please tell us which
specific issues you have on current version. When we said that current
version addresses all received comments, we truly believed that, though
it is possible we missed some by mistake (not intentionally). We are
actually looking forward for your review.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 05 Nov 2012 19:09:34 -0500

Hi Carlos,

> in the multicast space [...]"

This was a different discussion. Marco said *PFMIP* and 
*Transient*Binding* are different (which is obviously true) ... but your 
draft is unrelated to *PFMIP* - it does transfer context via the LMA ... 
just as *Transient*Binding* does. As mentioned earlier: It does not 
appear smart to me if we define Multicast solutions that mirror unicast 
approaches, but remain incompatible on the wire. (For a way how to do 
unicast-integrated fast handover support see 
http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07).

The second issue was *IPv4*support* - I suppose, PMIP acceleration 
protocols MUST provide IPv4 support. I don't see this in the current 
version.

Regarding further issues I raised longer ago, I searched, but cannot 
find my old email ... if time permits, I should review the draft in more 
detail.

Cheers,

Thomas

--

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 06 Nov 2012 10:58:34 +0000

Hi Thomas,

Thanks for refreshing these comments. Regarding the Transient Binding topic we honestly thought this was already clarified with the Marco’s mail in the handover-related discussion generated during last IETF meeting (a thread which involved draft-ietf-multimob-fast-handover, draft-schmidt-multimob-fmipv6-pfmipv6-multicast, and transient binding). Since it seems that we probably were wrong, let me go through this and the rest of the comments you provide.

== Transient binding ==

You pointed out a potential relationship between draft-ietf-multimob-fast-handover and RFC6058. I assume that, from the whole draft-ietf-multimob-fast-handover, you specifically see apparent similarities for the proactive handover case (due that in the reactive case there is no other interaction with the BCE -additional to what is mentioned in RFC5213- than checking a flag).

However this potential relationship is not actually the case for a number of reasons I will try to explain in this mail.

Basically, RFC6058 allows the maintenance of dedicated and separated forwarding rules for uplink and downlink, and the maintenance of two forwarding entries at the LMA respect to the MN, which allows the simultaneous delivery of data through pMAG and nMAG towards the MN. In draft-ietf-multimob-fast-handover, however, it is assumed a direct transition between the two active BCE states, as stated in RFC5213 (that is, the forwarding entry at LMA points to the nMAG as soon as the PBU is received from the nMAG, deleting the previous one pointing to the pMAG; it does not specify a BCE capable to refer to two proxy CoAs at the same time).

SIAL (draft-ietf-multimob-fast-handover) approach does not imply status change, nor any other temporal status, in the BCE, it just facilitates the storage and forwarding of configuration information, specifically the multicast address records providing the multicast subscription information that the MN is subscribed to. In the proactive handover case, these multicast address records are stored in the BCE once the MN de-registers from the pMAG. This info is stored as any other information, it does not trigger any action.
Later on in SIAL, once the MN attaches to a nMAG, the nMAG retrieves in the PBA configuration data from the LMA for serving the MN, as it does for instance for the link-local address to be used at the MAG. This configuration data in the SIAL approach does not impose any change in the forwarding plane, it only helps to accelerate the subscription by the nMAG of the content which the MN was receiving at the pMAG, instead of waiting for resolving the subscription information as specified in RFC6224.

Furthermore, in RFC6058 the transient binding is triggered by the nMAG, so this would correspond to a reactive handover case. In SIAL, as result of reactive case, the multicast address records have not been previously stored in the BCE, so an interrogation process is triggered towards the pMAG. So, the reactive handover case results on orthogonal procedures in both approaches.

== IPv4 ==

SIAL defines an signaling procedure internal to the network, specifically between MAGs and LMAs. There is no specific multicast signaling in SIAL, but just a multicast membership context transfer between PMIPv6 entities which can be transported either by using IPv4 or IPv6, depending on the specific deployment in the domain. From this point of view, there are not additional requirements or needs to that already specified in RFC5213, RFC5844 or RFC6224.

== Previous comments ==

I would need a more precise reference to that old comments not already addressed in the current version. Even if I take a look through the mail list, I would be grateful if you could identify yet open points. Maybe after reading again that mails and comments we both realized that have been already covered in the text.

Hope this clarifies

Best regards,

Luis

-----Mensaje original-----
De: Thomas C. Schmidt [mailto:[email-masked]]
Enviado el: lunes, 05 de noviembre de 2012 23:29
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]
Asunto: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt

Hi Luis,

I was just flying over the rams/sial draft and saw my previous comments untreated.

This was the transient binding below ... and IPv4 treatment ... and some more details I had commented about 10 - 15 months ago, but cannot quickly find my mail. Please have a look.

Cheers,

Thomas

-------- Original Message --------
Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding
Date: Mon, 30 Jul 2012 14:36:25 -0700
From: Thomas C. Schmidt <[email-masked]>
To: [email-masked] <[email-masked]>

Hi,

draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to nMAG - which in concept corresponds to the *Transient*Binding* in unicast RFC 6058 http://tools.ietf.org/html/rfc6058.

So the question is about protocol systematics: Do we want unicast and multicast protocol operations remain incompatible?

Cheers,

Thomas

On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote:
> De: [email-masked] [mailto:[email-masked]] En
> nombre de [email-masked] Enviado el: lunes, 22 de octubre de
> 2012 20:07

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 06 Nov 2012 12:51:14 -0500

Hi Luis,

thanks for your reply ... still I don't believe one can just talk away 
the issues that were raised.

[IPv4:]

You define new messages, states and behavior in your protocol without 
mentioning IPv4. Your definitions are exclusively for MLDv2 (why only 
version 2???). This cannot work with IPv4, and you need not only to 
specify IPv4-capable signaling + state, but also the 
coexistence-semantic and - most importantly - methods to treat IPv4 
address collisions (see RFC 6224 on that).

[RFC 6058:]

This RFC defines additional 'transient' binding states and corresponding 
behavior to 'seamlessly guide the transition' of context from pMAG to 
nMAG via the LMA by a proactive push. Even though I haven't worked it 
out, the approach should be able to carry your extensions and facilitate 
the protocol behavior you aim at. As mentioned earlier, it does not seem 
a systematic, IETF-style approach to have unicast and mutlicast 
protocols diverge to incompatibility.

There is of course the other aspect of proper credit:

  Two solutions of context transition in PMIP are (sensibly) possible:
  1. pMAG/AR -> nMAG/AR - that's (P)FMIP and was introduced by Rajeev et al.
  2. pMAG -> LMA -> nMAG - that's PMIP (reactive pull) and RFC6058 
(proactive push), the latter introduced by Marco et al.

I don't think it is legible to adopt the latter without even referencing.

In summary I strongly believe

  (i) you inevitably need to fix the IP version issue
  (ii) you should migrate your protocol operations to be compliant to 
RFC6058 ... otherwise you need at least to mention up front (abstract), 
why you build a solution that produces incompatibility with 
corresponding unicast protocols.

Cheers,

Thomas

--