[mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option
Tomasz Mrugalski <tomasz.mrugalski@gmail.com> Thu, 27 October 2011 12:18 UTC
Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1321F858C for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCH1TvNgFoOy for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:18:01 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C88221F8541 for <mif@ietf.org>; Thu, 27 Oct 2011 05:18:01 -0700 (PDT)
Received: by wyh22 with SMTP id 22so3232225wyh.31 for <mif@ietf.org>; Thu, 27 Oct 2011 05:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=xtCFd1EhoXs/yDEiwcueWftX5u+z56VHGaw6IooAp9U=; b=QIGMMbw/HGeDi4H6teAglM9pCDOAcKJXwi0r2PotaM6ZXHad6TzuIe7IxD+L2VBAlT f1PW7iUosSKohrVzaExdlmKZTsuF07nwz7wJSjprfQ2I8la+8+WiQPAqPiGiFBPbqzAk oCQ+tD0utoUZDzS2zIq64cBU5BInjZ3yObmjE=
Received: by 10.227.206.211 with SMTP id fv19mr15512221wbb.27.1319717878874; Thu, 27 Oct 2011 05:17:58 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id fi11sm9038274wbb.9.2011.10.27.05.17.56 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 05:17:57 -0700 (PDT)
Message-ID: <4EA94BF6.5020501@gmail.com>
Date: Thu, 27 Oct 2011 14:17:58 +0200
From: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: mif@ietf.org
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: Margaret Wasserman <margaretw42@gmail.com>, Hui Deng <denghui02@hotmail.com>
Subject: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2011 12:18:02 -0000
Dear Chairs, Dear MIF, DHCPv6 Route Option draft has been presented in MIF several times. It was also presented in DHC WG and most* (see below) comments were addressed. I would also like to point out that this draft incorporates changes after Routing Directorate review, especially insightful comments from Joel Halpern about potential problems in networks that use dynamic routing. The lastest (-03) drafts contains clear warning that configuring routing over DHCPv6 in networks that use dynamic routing is a very bad idea (unless you exactly now what you are doing). * Authors chose to not incorporate some of the comments, raised by authors of dlro draft. There was a discussion in MIF list. Route option authors believe that: 1. defining separate option for just default route would be wrong. Let me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways of specifying the same information—it creates a very clear potential for interoperability problems.". On a related note, I was involved in work on DS-Lite configuration over DHCPv6 and we initially had the same idea - define two options (address and FQDN) for the same thing. This approach was firmly rejected during IESG review. The message was clear: "choose one option". 2. conveying MAC (or link-layer in general) address is not necessary. There are other mechanisms like ND to obtain that information. Forcing this information on every client is just a waste of space as all clients that I know of can obtain this information on their own. They can do that in a timely manner, so raised argument about speed-up is not valid in my opinion. Another aspect is operational consideration. It would be very cumbersome to deploy and use. If operator changes interface in its router, DHCP configuration had to be updated and reconfigure procedure initiated. It could work in theory, but reconfigure is not commonly supported. DHCP server configuration would require knowledge of link-layer addresses of announced router(s). We could gain nothing by including MAC address, but get a lot of problems in the process. Therefore dhcpv6-route-option authors chose to not include link-layer information field. I would like to point out again that route-option proposal is extensible. It is designed as a minimal useful set of informations necessary for routing configuration. There are many more aspects of routing that may be useful in *some* cases. Therefore we made it clear that proposed options are extensible. If there are valid cases when extra information is useful, it should be defined as extension option. That's they recommendation I offer to anyone who says "can you add parameter X to route options? I really need it". To summarize this summary, we believe that mif-dhcpv6-route-option draft received enough reviews by experts in MIF, DHC and routing fields and is ready for WGLC. Therefore I'd like to ask MIF chairs to announce one. If we choose to have LC done in a timely fashion, we could discuss the results in Taipei. If that is the case, I would like to request time slot in Taipei meeting. I can't guess how many comments we will receive during WGLC, but I hope 10 or 15 minutes will be enough. Cheers, Tomek
- [mif] A request for Last Call on draft-ietf-mif-d… Tomasz Mrugalski
- Re: [mif] A request for Last Call on draft-ietf-m… Alexandru Petrescu
- Re: [mif] A request for Last Call on draft-ietf-m… maximilien mouton