Re: [netlmm] Local routing at the MAG

Hi Vijay,
  This is the simplest case of PMIP6 RO. We identified it as Case #1 (also Case #2 which is a very similar case) in draft-qin-netlmm-pmipro-00. The solution is as you said in the base draft.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay@wichorus.com>
To: "Koodli, Rajeev" <rkoodli@starentnetworks.com>; kchowdhury@starentnetworks.com
Cc: netlmm@ietf.org
Sent: Monday, July 7, 2008 4:16:24 PM
Subject: [netlmm] Local routing at the MAG

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