Re: [netext] Access Network Information option for Proxy Mobile IPv6

<Basavaraj.Patil@nokia.com> Thu, 14 July 2011 20:34 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F9511E8079 for <netext@ietfa.amsl.com>; Thu, 14 Jul 2011 13:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 vgUdI8MLzJKU for <netext@ietfa.amsl.com>; Thu, 14 Jul 2011 13:34:07 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 97CB811E807B for <netext@ietf.org>; Thu, 14 Jul 2011 13:34:07 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6EKY4UI007829; Thu, 14 Jul 2011 23:34:05 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 23:34:04 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 14 Jul 2011 22:34:04 +0200
Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.56]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.002; Thu, 14 Jul 2011 22:34:03 +0200
From: Basavaraj.Patil@nokia.com
To: sgundave@cisco.com, netext@ietf.org
Thread-Topic: [netext] Access Network Information option for Proxy Mobile IPv6
Thread-Index: AQHMQaSQXMIZLmGHTEmBkGbIARnb0ZTr0hcA
Date: Thu, 14 Jul 2011 20:34:02 +0000
Message-ID: <CA44B65A.1BBB4%basavaraj.patil@nokia.com>
In-Reply-To: <CA435D40.20E43%sgundave@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [172.19.59.136]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <D9F119F4EDC84C40B1F4D0C88459609E@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Jul 2011 20:34:04.0070 (UTC) FILETIME=[5F0CB460:01CC4265]
X-Nokia-AV: Clean
Subject: Re: [netext] Access Network Information option for Proxy Mobile IPv6
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2011 20:34:11 -0000

I reviewed this I-D and have a few questions:

1. Why does the LMA need to obtain the access network information from the
MAG? Can it not obtain the same from the AAA server with which it has an
interface?
The MN has to authenticate via the AN to the AAA server prior to PMIP6
being triggered. So I would expect that AAA has the information about the
access network which could then be obtained by the LMA.

2. Why does the binding cache at the LMA and/or MAG need to store the
information carried in the ANI option? I don¹t see how it would be used
from the document.

3. The statement : "In access systems where the mobile access gateway is
      attached to a micro-mobility domain such as IEEE 802.11 WLAN
      domain, the DHCP relay agent function in that micro-mobility
      domain may be configured to add the access network information in
      DHCP option (82), which is the DHCP Relay Agent Information option
      [RFC3046].  The mobile access gateway may learn the access network
      information from this option."
Seems like a lot of handwaving. Is there a DHCP option for carrying access
network information?
If you want this info to be carried in option 82, I would think that there
is a need to specify this in the DHC WG.

4. Can you give me an example of how the LMA would classify traffic or
treat Mns differently based on the information carried in the ANI option?
The statement:
"Policy systems in mobility architectures such as PCC [TS23203] and ANDSF
   [TS23402] in 3GPP system allow configuration of policy rules with
   conditions based on the access network information.  For example, the
   service treatment for the mobile node's traffic may be different when
   they are attached to a access network owned by the home operator than
   when owned by a roaming partner.  The service treatment can also be
   different based on the configured SSID in case of IEEE 802.11 based
   access networks.
"
Is IMO not very realistic.

5. And lastly consider the following scenario:
The LMA knows the identity of the MAG from which it receives BUs. If a MAG
is associated with a wifi AP then the LMA already knows (or can be
configured) about the MAGs AN details. And hence there is really no reason
to send that information in every BU. The LMA is already aware whether a
MAG is viewed as one that belongs to the home network or a visited
network. Hence I don¹t see the need for explicit signaling.

-Raj


On 7/13/11 4:33 PM, "ext Sri Gundavelli" <sgundave@cisco.com> wrote:

>Please comment on the draft related to carrying Access Network Information
>to the LMA.
> 
>
>7. Access Network Information Option for Proxy Mobile IPv6   10 Mins
>   I-D: 
>http://www.ietf.org/id/draft-gundavelli-netext-access-network-option-01.tx
>t
>   Presenter: Jouni Korhonen
>
>
>
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext