Re: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 27 October 2011 12:23 UTC

Return-Path: <alexandru.petrescu@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 CD89D21F8610 for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 F2p+-Roc3Elh for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 05:23:55 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8E98C21F85A4 for <mif@ietf.org>; Thu, 27 Oct 2011 05:23:54 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9RCNpve004170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Thu, 27 Oct 2011 14:23:51 +0200
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 p9RCNopQ005947 for <mif@ietf.org>; Thu, 27 Oct 2011 14:23:50 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9RCNnOj025581 for <mif@ietf.org>; Thu, 27 Oct 2011 14:23:50 +0200
Message-ID: <4EA94D55.1080605@gmail.com>
Date: Thu, 27 Oct 2011 14:23:49 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: mif@ietf.org
References: <4EA94BF6.5020501@gmail.com>
In-Reply-To: <4EA94BF6.5020501@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [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:23:55 -0000

Can you provide software for this?  Please contact me off-list if yes.

Alex

Le 27/10/2011 14:17, Tomasz Mrugalski a écrit :
> 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 mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>