Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Fri, 09 December 2011 00:31 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D481F0C38 for <multimob@ietfa.amsl.com>; Thu, 8 Dec 2011 16:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Level:
X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0sjUtB094RO for <multimob@ietfa.amsl.com>; Thu, 8 Dec 2011 16:31:53 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 019D11F0C36 for <multimob@ietf.org>; Thu, 8 Dec 2011 16:31:53 -0800 (PST)
Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E80C52780A5; Fri, 9 Dec 2011 09:31:48 +0900 (JST)
Date: Fri, 09 Dec 2011 09:31:48 +0900
Message-Id: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp>
To: sarikaya@ieee.org, sarikaya2012@gmail.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <CAC8QAcc9NhSKO5Fz9C9JcVsku+OSXcBWe_PgjqoySMiA3doJ_w@mail.gmail.com>
References: <CAC8QAcc9NhSKO5Fz9C9JcVsku+OSXcBWe_PgjqoySMiA3doJ_w@mail.gmail.com>
X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: multimob@ietf.org
Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 00:31:53 -0000

Behcet,

>   There was consensus on the tunnel convergence solution draft in Taipei.
>  This mail is to confirm the consensus.
> 
> 
> This document can be found at:
> http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt
> 
> This mail starts a WG adoption call on this draft.
> 
> The intended status for this document is proposed standard.
> If adopted, the draft will be named:
> 
> draft-ietf-multimob-pmipv6-tunnel-convergence.
> 
> Please your comments by December 15, 2011.

I don't think there was any consensus about adoption of this draft at
the last meeting.

We've proposed the tunnel convergence problem solution draft;
draft-asaeda-multimob-pmip6-extension-07

Why you eliminate the discussions in the meeting and the chance to
discuss in the mailing list?

Before explaining the thoughts about draft-zuniga draft, I'd make you
understand the situation of our draft.

1. I think Thomas always misunderstands the point. MAG is a router and
   has its own RIB. PIM can use its RIB and can copy it to its MRIB.
   When we need to define dedicate multicast routes, we can configure
   the ones. We do not need PMIPv6-based policy routing for RPF check.
   After the last meeting I understand Thomas's misinterpretation
   comes from this. I will clearly emntion it in the revised version.

2. My -06 draft defines GRE type M-Tunnel to define MAG's upstream IF
   to distinguish the regular IPv6 tunnel. But according to the previous
   discussion in the ML, we eliminate the way to distinguish unicast
   and multicast tunnels to make the story simple in -07 draft.
   But I recognized this elimination was not always correct, because
   we cannot assume that a unocast route toward sources outside of
   PMIPv6 domain defined in MAG's RIB always goes through the regular
   IPv6 tunnel. Therefore GRE type M-Tunnel will be recalled from -06
   to the revision -08.

3. One important discussion missing in -06 is the way to select a single
   M-Tunnel when multiple M-Tunnels are configured for the same (S,G)
   or (*,G). This can be addressed in the revised draft, too.

For your question, I don't think
draft-zuniga-multimob-pmipv6-ropt-01.txt should be adopted now.

Regards,
--
Hitoshi Asaeda