Re: [MEXT] Prefix Delegation documents

Behcet Sarikaya <behcetsarikaya@yahoo.com> Fri, 23 November 2007 04:16 UTC

Return-path: <mext-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPyA-0005O6-OL; Thu, 22 Nov 2007 23:16:46 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPy9-0005Nq-CZ for mext@ietf.org; Thu, 22 Nov 2007 23:16:45 -0500
Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvPy8-0001t6-4S for mext@ietf.org; Thu, 22 Nov 2007 23:16:45 -0500
Received: (qmail 46212 invoked by uid 60001); 23 Nov 2007 04:16:43 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=II5yNgUFibBlVoGfoe6sCmiLy2ulF633a34yv5m7rv/AvA2rogGASqnC49GurG6gfoBZbRIl2M2mMqHTofZ1YUJkOs4WIbfA6ll9zSwxjKH4ZlOkQgcKmmvpOfWmGamWllyqqkdVDKu0Z12qXlOLg6YTS5OEO+QmKv6supYdukg=;
X-YMail-OSG: jV49Yd0VM1ksutSwFeHcobYjZQRq4OHqmWKbR0RlLAg2_.rjtoYbwb6WIM1Xkn5KlH8RmsULCx3rZkPuN_25wf8AZRP2Ueah_cZdjM8Koc.TpSZ.diZTLQITTA--
Received: from [71.123.247.57] by web84107.mail.mud.yahoo.com via HTTP; Thu, 22 Nov 2007 20:16:43 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152
Date: Thu, 22 Nov 2007 20:16:43 -0800
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Subject: Re: [MEXT] Prefix Delegation documents
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
MIME-Version: 1.0
Message-ID: <550106.45780.qm@web84107.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Cc: mext@ietf.org
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1471929613=="
Errors-To: mext-bounces@ietf.org

Hi Vijay,
  I agree with you.
Regarding the status of the draft, it is possible to have the document to be standards track even if it does not define any new messages/parameters. An example is draft-ietf-16ng-ipv6-over-ipv6cs-11
Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: mext@ietf.org
Sent: Thursday, November 22, 2007 3:56:09 PM
Subject: Re: [MEXT]  Prefix Delegation documents

I don't believe it is necessary to extend DHAAD for NEMO prefix
delegation. The mobile router could assume that the home agent it
is bootstrapping does support a mechanism for assigning prefixes
for the mobile network. I don't think we have any home agents
deployed today that support mobile routers to worry about. :) So
it would be safe to assume that a home agent that supports mobile
routers also supports a mechanism to assign a mobile network
prefix.

Vijay

Pascal Thubert (pthubert) wrote:
> Hi Alex
> 
> My take is that similar DHAAD flags should be present in both drafts
 for
> similar reasons; last I proposed it was rejected; I think that the
> argument was that locating the HA should be a DNS issue anyway. From
 the
> discussion we had recently with Romain, I still think that DHAAD and
 DNS
> can be complementary.
> 
> You have some good points on DNS. But at this time we address
 prefixes
> not hosts. How the hosts on the MNP get names and publish those is an
> interesting issue but out of scope at this time.
> 
> The fact that the HA uses NEMO extensions to pass the prefix to the
 MR
> does not preclude the use of a DHCP-PD server in the back end. It's
 just
> abstracting and simplifying that interaction. One problem with the
> DHCP-PD draft is lifetime of the lease: should it die with the MR-HA
> tunnel? The Nemo based draft is conscious of the volatility of the
> tunnel and the HA proxies the PD process for the MR based on the MR
> demands.
>  
> 
> Pascal
> 
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
>> Sent: Wednesday, November 21, 2007 6:33 PM
>> To: Pascal Thubert (pthubert)
>> Cc: Vijay Devarapalli; Teco Boot; mext@ietf.org
>> Subject: Re: [MEXT] Prefix Delegation documents
>>
>> Pascal Thubert (pthubert) wrote:
>>> Hi Vijay
>>>
>>> My proposal to break the tie is this:
>>>
>>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as
 it
>>>  documents a way to use DHCP-PD but does not need new exchanges.
>> But as Romain pointed out, DHCP-PD as specified in this draft
 extends
>> DHAAD by adding a new D flag.  If we want to avoid the use of the
 new D
>> flag then we should (probably) say in the DHCP-NEMO-PD draft how
 that
>> DHCPv6 Solicit is sent through the MR-HA tunnel (or not through
 tunnel)
>> and then relayed by the HA on the home link (or the HA is the DHCPv6
>> Server).
>>
>> I think even if we move it to the Informational track then we still
> need
>> to improve some stuff in it according to implementation.  Or just
 let
> it
>> float... I don't know.
>>
>>> Last I checked, some components were still missing but Ralph knows
>>> better.
>>>
>>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard
>>> track. The draft is agnostic to the delegation mechanism in the
>>> backend and does not have dependencies.
>> But it extends MIP6, right?  (adds flags in messages).
>>
>>> It proposes an integrated mechanism that fits the general MIP6 /
 NEMO
>>> approach and formats.
>>>
>>> What do you think?
>> I think we should not extend MIP6 to do prefix allocation.  BEcause:
>>
>> -I think addressing autoconfiguration mechanisms DHCP and others are
>>  already there for us to reuse and enhance eventually, no need to
> extend
>>  MIP6.
>> -what happens when MIPv6 allocates a prefix and PMIPv6 allocates one
>>  as well, but in a different way? (currently PMIPv6 doesn't seem to
> use
>>  NEMO-MIP6-PD flags neither does NEMO-MIP6-PD use PMIPv6 way of
> putting
>>  0 to mean request prefix).  Are the MIP6 and PMIP6 means to
 allocate
>>  prefixes equivalent?
>> -what happens when we want the prefix delegated to the MR to be
>>  accompanied by a delegation of responsibility of the DNS reverse
>>  resolution as well?  Can we reuse DHCP-DNS interactions (e.g. DNS
>>  update RFC2136)?  Or should we design a new MIP6-DNS interaction?
>>
>> That's simply opinion.  I'm not sure about other criteria that came
 to
>> give the suggestion you made.
>>
>> Alex
>>
>>
>>
 ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security
 System.
>> For more information please visit http://www.messagelabs.com/email
>>
 ______________________________________________________________________


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext



_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext