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
On 06.11.2012 05:58, LUIS MIGUEL CONTRERAS MURILLO wrote:
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
--
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 °
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob
