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 protected]]
Enviado el: lunes, 05 de noviembre de 2012 23:29
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email protected]
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.

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 protected]>
To: [email protected] <[email protected]>

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

On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote:
> 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 protected] [mailto:[email protected]] En
> nombre de [email protected] Enviado el: lunes, 22 de octubre de
> 2012 20:07
> Para: [email protected]
> CC: [email protected]
> 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 protected]
> 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 protected]
> https://www.ietf.org/mailman/listinfo/multimob
>

--

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 °

________________________________

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 protected]
https://www.ietf.org/mailman/listinfo/multimob

Reply via email to