[multimob] Multicast router operation in MAGs in draft-asaeda-multimob-pmip6-extension-11

Sérgio Figueiredo <sfigueiredo@av.it.pt> Wed, 07 November 2012 15:37 UTC

Return-Path: <sfigueiredo@av.it.pt>
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 08BDF21F8C03 for <multimob@ietfa.amsl.com>; Wed, 7 Nov 2012 07:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level:
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRbxeZxXC7ua for <multimob@ietfa.amsl.com>; Wed, 7 Nov 2012 07:37:40 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id E942C21F8C10 for <multimob@ietf.org>; Wed, 7 Nov 2012 07:37:37 -0800 (PST)
Received: from [193.136.93.29] (account sfigueiredo@av.it.pt [193.136.93.29] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66946549 for multimob@ietf.org; Wed, 07 Nov 2012 15:37:30 +0000
Message-ID: <509A803A.1040007@av.it.pt>
Date: Wed, 07 Nov 2012 15:37:30 +0000
From: Sérgio Figueiredo <sfigueiredo@av.it.pt>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: multimob@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [multimob] Multicast router operation in MAGs in draft-asaeda-multimob-pmip6-extension-11
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: Wed, 07 Nov 2012 15:37:45 -0000

Hi Hitoshi, Pierrick,

I have 2 questions:

1) how is the operation of MAGs using a M-Tunnel different from a MR 
deployed in a MAG using MTMA mode? I didn't go through both drafts in 
detail, so I may be missing something..

2) The second issue is more specific and is related to the correct 
operation of your proposal (which I would sayz also applies to section 
4.3 of "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6").

It is said in the draft that "The MAG selects only one upstream 
interface (either M-Tunnel interface or physical interface) for a 
multicast channel by the Reverse Path Forwarding (RPF) algorithm."
It is correct that RPF will lead to the selection of a single interface 
for any multicast channel. Although, the M-Tunnel will not be selected 
following RPF unless one of two options is followed:
1) a specific route entry to the RP (RPT) or to the source (SPT) exists 
in the RIB, and it "points to" the tunnel interface;
     - I assume such a tunnel won't be running a routing protocol like 
OSPFv3, so I find this case very improbable / impossible (?)
2) MRIB is (manually) configured with an entry stating that the RP's (or 
source's) prefix is accessed via the M-tunnel;
      - in RFC4601 it is stated regarding MRIB that "The routes in this 
table may be taken directly from the unicast routing table, or they may 
be different and provided by a separate routing protocol such as MBGP". 
In my opinion, this gives space to feeding MRIBs from MAGs in a "novel" 
way for PMIPv6 environments..

Please correct me if any of my conclusions / observations are wrong, but 
my main point is, the exact way how the MRIB is filled should be 
described, as it is crucial to the correct operation of the proposal.

Best regards,
Sérgio