Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 02 November 2012 00:31 UTC

Return-Path: <alexandru.petrescu@gmail.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 D94E421F989D for <netext@ietfa.amsl.com>; Thu, 1 Nov 2012 17:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 YeVUcLT2aGJL for <netext@ietfa.amsl.com>; Thu, 1 Nov 2012 17:31:15 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 110E721F95E3 for <netext@ietf.org>; Thu, 1 Nov 2012 17:31:14 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA20VDNG012414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <netext@ietf.org>; Fri, 2 Nov 2012 01:31:13 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA20VD9B026748 for <netext@ietf.org>; Fri, 2 Nov 2012 01:31:13 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (arletty1-201-9.intra.cea.fr [132.166.201.9]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA20UwFm010090 for <netext@ietf.org>; Fri, 2 Nov 2012 01:31:13 +0100
Message-ID: <50931442.5040009@gmail.com>
Date: Fri, 02 Nov 2012 01:30:58 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: netext@ietf.org
References: <CAE175BA.2FD9D%sgundave@cisco.com>
In-Reply-To: <CAE175BA.2FD9D%sgundave@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01
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: Fri, 02 Nov 2012 00:31:16 -0000

Le 10/11/2011 20:36, Sri Gundavelli a écrit :
> I agree. I think we should simply assume the DHCPv6 server and the
> LMA are collocated. For the split case, we loosely specify the
> assumptions and the interface should be out of scope.

In case LMA is separated from the DHCPv6 Server we propose two message
exchange diagrams, depending on whether or not the DHCP Server can be
modified or not.  The proposals are in the individual submission
draft-petrescu-netext-pmip-nemo-01 pages 8 and 9.

What are the assumptions that you refer to above?

Alex

>
>
> Sri
>
>
> On 11/10/11 1:29 PM, "Basavaraj.Patil@nokia.com"
> <Basavaraj.Patil@nokia.com> wrote:
>
>>
>> Inline:
>>
>> On 11/10/11 2:21 PM, "ext jouni korhonen" <jouni.nospam@gmail.com>
>> wrote:
>>
>>> Raj,
>>>
>>> On Nov 10, 2011, at 2:30 PM, zhou.xingyue@zte.com.cn wrote:
>>>
>>>>> 4. If the prefixes (delegated) are provided by a DHCP server
>>>>> (and not the LMA), how does the LMA get informed about these?
>>>>> In the PBU? How do you ensure that "All the mobile network
>>>>> prefixes managed in the DR MUST be reachable via local
>>>>> mobility anchor (LMA)" when they are not assigned by the
>>>>> LMA?
>>>> [Joy]Here it assumes that the LMA can interact with the DHCPv6
>>>> Server within some other mechanisms e.g. Radius.
>>>
>>> The situation is the same as with PMIP6 and DHCPv6 in general.
>>> The DHCPv6 server and the LMA has to be in sync. There is no need
>>> for an interface as everything can be managed with configuration.
>>> But that does not preclude having an interface between the LMA
>>> and the DHCPv6 server.
>>
>> How do you keep the DHCPv6 server and the LMA in sync? Is it
>> considered out-of-scope and the actual method about how they are
>> synced not specified? If the DHCPv6 server and LMA are co-located,
>> it could be easier. If they are not, then it may be an issue. The
>> argument that you can use a Radius type interface between DHCPv6
>> server and the LMA is not good enough. Is there such a
>> specification? The Netext WG has only specified the RADIUS
>> interactions between a AAA server and the MAG/LMA entities.
>>
>> -Raj
>>
>>>
>>> - Jouni
>>>
>>>
>>>
>>
>> _______________________________________________ netext mailing
>> list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext
>
> _______________________________________________ netext mailing list
> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext
>