RE: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

"Laganier, Julien" <julienl@qualcomm.com> Fri, 10 September 2010 21:17 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA99A3A68CB; Fri, 10 Sep 2010 14:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHQwPFRtP-mq; Fri, 10 Sep 2010 14:17:48 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 09FD43A6884; Fri, 10 Sep 2010 14:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1284153495; x=1315689495; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Alexandru=20Petrescu=20<alexandru.petrescu@gmail.c om>|CC:=20mext=20<mext@ietf.org>,=20IETF=20Discussion=20< ietf@ietf.org>|Date:=20Fri,=2010=20Sep=202010=2014:18:12 =20-0700|Subject:=20RE:=20[MEXT]=20Last=20Call:=20draft-i etf-mext-nemo-pd=20(DHCPv6=20Prefix=0D=0A=09Delegation=20 for=20NEMO)=20to=20Proposed=20Standard|Thread-Topic:=20[M EXT]=20Last=20Call:=20draft-ietf-mext-nemo-pd=20(DHCPv6 =20Prefix=0D=0A=09Delegation=20for=20NEMO)=20to=20Propose d=20Standard|Thread-Index:=20ActRDwMYsVpK1bxkQ/qEgPjQbPrs mwAAjPEw|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1 F6826E37E@NALASEXMB04.na.qualcomm.com>|References:=20<C8B 03E68.14FA4%hesham@elevatemobile.com>=0D=0A=09<4C8A1DEF.9 050403@gmail.com>=0D=0A=09<BF345F63074F8040B58C00A186FCA5 7F1F6826E30A@NALASEXMB04.na.qualcomm.com>=0D=0A=20<4C8A6D 0C.5030403@gmail.com>|In-Reply-To:=20<4C8A6D0C.5030403@gm ail.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=3gXLigyV7/IqqLA9JKEkG65aDsjkYbEtS+zB1VuGA1E=; b=EcCWp0pa7YT/Xhz9HJjbrZeeI0T2BxsR0wmdw/hmdNZVn4pC0yKbrsQU VyAqajiiJuA4CYTvR7gU37j9jJx+W3X0/g97fj3UWgbBzHypwPeW9DYB9 Hamk2SBVIBQh9bqZraV5r43T3OTxzuOyrVzOgZGSxwZtqWuiuCXcpM4Ga s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6102"; a="53950596"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 10 Sep 2010 14:18:15 -0700
X-IronPort-AV: E=Sophos;i="4.56,347,1280732400"; d="scan'208";a="12744844"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Sep 2010 14:18:15 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Sep 2010 14:18:15 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 10 Sep 2010 14:18:14 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Date: Fri, 10 Sep 2010 14:18:12 -0700
Subject: RE: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard
Thread-Topic: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard
Thread-Index: ActRDwMYsVpK1bxkQ/qEgPjQbPrsmwAAjPEw
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6826E37E@NALASEXMB04.na.qualcomm.com>
References: <C8B03E68.14FA4%hesham@elevatemobile.com> <4C8A1DEF.9050403@gmail.com> <BF345F63074F8040B58C00A186FCA57F1F6826E30A@NALASEXMB04.na.qualcomm.com> <4C8A6D0C.5030403@gmail.com>
In-Reply-To: <4C8A6D0C.5030403@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Discussion <ietf@ietf.org>, mext <mext@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 21:17:50 -0000

Alexandru Petrescu wrote:
> 
> Le 10/09/2010 18:57, Laganier, Julien a écrit :
> > Alexandru Petrescu wrote:
> >>
> >> Le 10/09/2010 11:58, Hesham Soliman a écrit :
> >>>
> >>> On 10/09/10 7:55 PM, "Alexandru
> >>> Petrescu"<alexandru.petrescu@gmail.com>  wrote:
> >>>
> >>>> Le 10/09/2010 11:48, Hesham Soliman a écrit :
> >>>>>>>
> >>>>>>> =>     Who cares, specify it in your product
> >>>>>>> description. The IETF doesn't specify how to build
> >>>>>>> products.
> >>>>>>
> >>>>>> Hmm... to me it is a very IETF sensitive issue the Router
> >>>>>> vs Host. For example, an ND spec says distinctively what a
> >>>>>> Host and what a Router does, e.g. a Host does not respond
> >>>>>> to Router Solicitation.
> >>>>>
> >>>>> =>    Yes and it does so on a per-interface basis, not on a
> >>>>> per-machine basis.
> >>>>
> >>>> Yes, and the Mobile Router is a Router on its egress interface
> >>>>  when connected at home, as per spec.  It is that interface
> >>>> that needs a default route automatically configured.
> >>>
> >>> =>   Ok, so you're happy with it being half host half router
> >>> when it's away from home?
> >>
> >> When it is away from home it is fully a Host on the egress
> >> interface. When at home fully Router on same.  I am happy with it
> >> this way.
> >>
> >>> If so then let it do the same at home. Otherwise, I don't know
> >>> how you want to fix this in this WG.
> >>
> >> It would mean to specify it to be a at home, be first a Host (get
> >> default route) then change and become a Router, but still at home.
> >>
> >> This behaviour could be set in the DHCPv6-PD-NEMO draft, being
> >> under discussion now.
> >
> > This is a non issue for this draft. This is not specific to NEMO but
> > generic to any DHCPv6 Prefix Delegation setup where the requesting
> > router needs to configures an address on its north side.
> 
> Right... and a default route - that's the blocking point to me: I have
> all this shiny software and RFC but no automatic default route, I have
> to manually configure it.

If you agree that this is generic to DHCPv6 prefix delegation and not limited to this specific application of DHCPv6 prefix delegation to a NEMO environment, then this draft can proceed.

If you are missing a mechanism to get a default route on a DHCPv6 prefix delegation requesting router, you can write a draft and submit it to the DHC WG.

I also don't know what the problem is on most cases. Presumably the requesting router's default route is to send packet to the delegating router. 

> > It can do so as per the deployment specifics, including, but not
> > limited to, acting as a host on the north interface and as a router
> > on south interfaces -- please remember that Neighbor Discovery is
> > specified on a per-interface basis.
> 
> It's not sufficient to say Mobile Router always acts as a Host on the
> North interface.  Because it must act as a Router too on its North
> interface.  It must join the all-routers multicast address on the home
> link, in order to forward packets from hosts on the home links towards
> LFNs.
> 
> If you don't like my default route comment then you could also just
> write in DHCPv6-PD-NEMO "this does not configure a default route on the
> Mobile Router, neither SLAAC".

You agreed earlier that this is generic to DHCPv6 prefix delegation and not specific to NEMO so this draft is NOT the place to digress on default routes for DHCPv6 prefix delegation.
 
> > [ I also note that this draft has been more than 2 years in the MEXT
> > working group in which you are participating, which gave you ample
> > time to comment on this and other things... ]
> 
> Note taken and I owe explanation.  If you wish consider my comments
> non-blocking, as comments to a soon-to-be-Request-For-Comments.

As you agreed earlier that this is generic to DHCPv6 prefix delegation and not specific to NEMO I do not consider this as blocking. 
 
> I simply did not have neither the software nor the network testbed to
> prototype until now.  Obtaining that is not easy, takes planning and
> time. E.g. a stable DHCPv6-PD was available only lately from ISC
> despite early initial availability.  It was mainly written for ISP-to-House
> deployments which are very different than Mobile Router moving around.
> 
> If you wish too, you could bring it back from IESG to here and I will
> comment further on it to work with real Relay, to solve
> the sync between Prefix Table, Routing Table, radvd.conf, lease file,
> to require Relay to insert route (currently it doesn't!), to respect 'M',
> and so on.

We are not bringing it back to the MEXT WG for something that is not related to the MEXT WG but generic to DHCPv6 prefix delegation.
 
> Or we could just deliver to IESG and see past.  I am fine with all
> options.

This is what we are doing.

If you really think there's a missing piece, write a draft and submit it to the DHC WG.

--julien