[netlmm] Local routing at the MAG

"Vijay Devarapalli" <vijay@wichorus.com> Mon, 07 July 2008 21:16 UTC

Return-Path: <netlmm-bounces@ietf.org>
X-Original-To: netlmm-archive@optimus.ietf.org
Delivered-To: ietfarch-netlmm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDD928C268; Mon, 7 Jul 2008 14:16:44 -0700 (PDT)
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D3328C268 for <netlmm@core3.amsl.com>; Mon, 7 Jul 2008 14:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YncaMdwc6fG for <netlmm@core3.amsl.com>; Mon, 7 Jul 2008 14:16:43 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 6CE9A28C248 for <netlmm@ietf.org>; Mon, 7 Jul 2008 14:16:22 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 07 Jul 2008 17:16:24 -0400
Message-ID: <DE33046582DF324092F2A982824D6B03039BEDD5@mse15be2.mse15.exchange.ms>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Local routing at the MAG
Thread-Index: AcjgdrXWM9TukNV+TqqkhUKOXqlXbw==
From: Vijay Devarapalli <vijay@wichorus.com>
To: "Koodli, Rajeev" <rkoodli@starentnetworks.com>, kchowdhury@starentnetworks.com
Cc: netlmm@ietf.org
Subject: [netlmm] Local routing at the MAG
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netlmm-bounces@ietf.org
Errors-To: netlmm-bounces@ietf.org

Hi Rajeev, Kuntal,

I looked at draft-koodli-netlmm-local-forwarding. I think it is a good
idea.

The PMIPv6 base specification already allows a MAG to optimize the
traffic when it figures out that both mobile nodes are attached to it.
See section 6.10.3 of draft-ietf-netlmm-proxymip6-18.txt. However, this
decision is based on local policy on the MAG. The base PMIPv6 document
also says 

   This decision of path optimization SHOULD be based on the policy
   configured on the mobile access gateway, but enforced by the mobile
   node's local mobility anchor.  The specific details on how this is
   achieved are beyond of the scope of this document.

I think draft-koodli-netlmm-local-forwarding could be the out-of-scope
mechanism referred to in the base document. Also,
draft-koodli-netlmm-local-forwarding should refer to section 6.10.3 of
the base spec. 

I have a few questions on the draft.

Why does the LMA have to authorize local routing per-pair of mobile
nodes? Can't it tell the MAG to apply local routing whenever possible?

Would it make sense to also allow the MAG to request the LMA for local
routing authorization when it detects a flow between two mobile nodes
attached to it? Does the local forwarding have to be triggered by the
LMA always?

Section 5.1 says

      MAY contain
      the remote MAG IPv6 address option, which is identical to the HNP
      option except for Prefix Length equal to 128 bits.

What indicates the presence of the remote (or peer) MAG IP address in
the LFRQ message? You might need a flag in the reserved field.

Finally, have you guys considered using the Generic Signaling message
(or the generic notification message as it was called before) instead of
defining a new mobility header message?

Vijay
_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www.ietf.org/mailman/listinfo/netlmm