Subject: [multimob] FW: New Version Notification for draft-ietf-multimob-pmipv6-ropt-00.txt

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 5 Mar 2012 12:07:43 -0500

Dear all,

We have uploaded the joint solution WG draft to the "PMIPv6 routing optimizations to avoid tunnel convergence" problem. We tried to address the comments received on the list as well as during the meeting.

http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-ropt-00.txt 

Your comments on the new draft are appreciated.

We look forward to discussing with you on the list and at the Paris meeting.

Best regards,

Juan-Carlos, et al.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 11:52 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Zuniga, Juan Carlos;
> [email-masked]
> Subject: New Version Notification for draft-ietf-multimob-pmipv6-ropt-
> 00.txt
> 
> A new version of I-D, draft-ietf-multimob-pmipv6-ropt-00.txt has been
> successfully submitted by Luis M. Contreras and posted to the IETF
> repository.
> 
> Filename:	 draft-ietf-multimob-pmipv6-ropt
> Revision:	 00
> Title:		 Multicast Mobility Routing Optimizations for Proxy
> Mobile IPv6
> Creation date:	 2012-03-04
> WG ID:		 multimob
> Number of pages: 29
> 
> Abstract:
>    The MULTIMOB group has specified a base solution to support IP
>    multicasting in a PMIPv6 domain [RFC6224].  In this document, some
>    enhancements to the base solution are described.  These enhancements
>    include the use of a multicast tree mobility anchor as the
>    topological anchor point for multicast traffic, as well as a direct
>    routing option where the MAG can provide access to multicast content
>    in the local network.  These enhancements provide benefits such as
>    reducing multicast traffic replication and supporting different
>    PMIPv6 deployments scenarios.
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 06 Mar 2012 00:33:31 +0100

Dear Juan-Carlos et al.,

just a quick response from a first browse through the document:

  Section 3:

  * The statement
    "The MTMA connects to the MAG as described in [RFC6224] and it can
    reuse native PMIPv6 features such as tunnel establishment and
    security [RFC5213], heartbeat [RFC5847], etc."
    is pretty vague and unclear to me - tunnel management of PMIP is 
between
    MAGs and LMAs ... but MTMA cannot act like an LMA (it has no 
MN-specific state),
    so how would it be able to perform dynamic tunnel management?

  * I don't understand the sense of "3.3.2.  MAG as Multicast Router" -
    if there is only one static upstream to the MTMA, a dynamic routing
    protocol at the MAG seems useless.

  * You should address and resolve the problem of IPv4 traffic in 
accordance
    with RFC 5213.

  Section 4:

  * In Section "4.3.1.  MAG as MLD Proxy" you speak about "every one of
    the MLD proxy instances invoked in the MAG" - why multiple instances?
    What shall each instance do?

  * In Section "4.3.1.1.  Multicast Establishment" it is shown in the flow
    chart that membership queries are issued from the MR - these are 
periodic
    queries which are unrelated to handoffs - thus they do not operate 
synchronized
    and therefore generate a possibly large delay - was this intended?

  * In Section "4.3.2.  MAG as multicast router" - I find a section of 
essentially
    zero content. This is unfortunate, since the deployment of a 
multicast routing
    protocol in a PMIP domain is of enhanced delicacy and full of traps, 
as we have
    seen from the repeated (fruitless) attempts Hitoshi has made. This 
should be explained
    in utmost precision, as there is no "out-of-the-box" way to do it.

So far for a first scratch - I'll be happy to review a more profound 
version of the draft in detail.

Cheer from the Cebit,

Thomas

On 05.03.2012 18:07, Zuniga, Juan Carlos wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> 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 °

---

From: Aaron Feng <[email-masked]>
Date: Wed, 7 Mar 2012 11:46:05 +0800

Hi,
I'm not sure about how the MAG match the MTMA?  Here are two ways in my
opinion.
1) The MAG can ONLY matches ONE MTMA while MTMA can match some MAGs
2) The multicast address can be divided into different sets and each MTMA
is responsible for each specific set, in that way, MAG can match different
MTMAs.
Both can avoid tunnel convergence.  However, maybe you have another idea.
What's your choice?
Regards,
Aaron

2012/3/6 Zuniga, Juan Carlos <[email-masked]>

> Dear all,
>
> We have uploaded the joint solution WG draft to the "PMIPv6 routing
> optimizations to avoid tunnel convergence" problem. We tried to address the
> comments received on the list as well as during the meeting.
>