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
- [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- [MEXT] Re: [nemo] Prefix Delegation documents Romain KUNTZ
- [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- [MEXT] Re: [nemo] Prefix Delegation documents Romain KUNTZ
- [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- [MEXT] Re: [nemo] Prefix Delegation documents Romain KUNTZ
- RE: [MEXT] Re: [nemo] Prefix Delegation documents Pascal Thubert (pthubert)
- RE: [MEXT] Re: [nemo] Prefix Delegation documents Teco Boot
- Re: [MEXT] Re: [nemo] Prefix Delegation documents Romain KUNTZ
- Re: [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- [MEXT] Re: [nemo] Prefix Delegation documents Romain KUNTZ
- [MEXT] Re: [nemo] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Re: [nemo] Prefix Delegation documents Vijay Devarapalli
- Re: [MEXT] Re: [nemo] Prefix Delegation documents Sebastian Thalanany
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Prefix Delegation documents Vijay Devarapalli
- RE: [MEXT] Prefix Delegation documents Teco Boot
- Re: [Autoconf] RE: [MEXT] Prefix Delegation docum… Alexandru Petrescu
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Prefix Delegation documents Vijay Devarapalli
- Re: [MEXT] Prefix Delegation documents Vijay Devarapalli
- Re: [MEXT] Prefix Delegation documents Behcet Sarikaya
- RE: [MEXT] Prefix Delegation documents Teco Boot
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Prefix Delegation documents marcelo bagnulo braun
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- Re: [MEXT] Prefix Delegation documents Alexandru Petrescu
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- RE: [MEXT] Prefix Delegation documents Pascal Thubert (pthubert)
- Re: less messages (was: [MEXT] Prefix Delegation … Alexandru Petrescu