Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

"Bernie Volz (volz)" <volz@cisco.com> Thu, 05 December 2013 13:35 UTC

Return-Path: <volz@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE01ADFB7 for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2013 05:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLkRfPwqvMlk for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2013 05:34:58 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 53F611ADFA3 for <v6ops@ietf.org>; Thu, 5 Dec 2013 05:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1386250495; x=1387460095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eTC9wSWRWqJJ0rMhBSUeiJZEKo7BLB9777XeRd+Cmw8=; b=FncpWi+tQYgICkv8zaH3vNPl6HRNdell8h7ybvOfzo61RPOFiKvPJsX6 Dd2WFBEpYpYE7nHbGJ066rZ1D6NJaTNnIMwpQp+U4nrx9lRf6MlQVZgr2 Ju5VKXY4I0RP0phyOerbmhbAZnhJQ3hhSu/Juzk7rEXCkVAR5qEtdJThQ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFACeAoFKtJV2c/2dsb2JhbABTBoMHOLk/gRoWdIIlAQEBAwEBAQFiBwIIAQIFCwIBCBEDAQIBLiEGCx0IAgQOBQkSh1UDCQYNsg6IDQ2HGxeMb4FOEDMHBoMagRMDiQqNH4FrgTCLKoU5gWuBPg
X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="scan'208";a="4537376"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 05 Dec 2013 13:34:54 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB5DYsUA014233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 13:34:54 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 07:34:54 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
Thread-Index: AQHO63G69dtoxzvWTEqg/AfsgX9kzJpGBasA//+hABE=
Date: Thu, 05 Dec 2013 13:34:53 +0000
Message-ID: <5262E1D6-8537-4C7D-A0D1-56FBC257AFC2@cisco.com>
References: <alpine.OSX.2.00.1311271353550.3903@ayourtch-mac>, <52A07C4E.5050004@gmail.com>
In-Reply-To: <52A07C4E.5050004@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 13:35:00 -0000

This is an issue to clarify in this document (it may already be clear, but that was one area I need to confirm in a reread) - it old compares address assignment mechanisms, not prefix delegation. There's no alternative for prefix delegation, so nothing to compare with. The routing issues for PD are a bit different than for addresses.

- Bernie (from iPad)

> On Dec 5, 2013, at 8:15 AM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote:
> 
> Thanks for the draft.  IMHO it goes in a good direction to compare what
> can be done with DHCPv6 vs RA.
> 
> I have some comments.
> 
>> DHCPv6 needs at least 2 packets.  RA is just one packet.
> 
> This varies.  It is mainly yes.
> 
> But, an initial exchange is at minimum 4 DHCPv6 messages (including a
> costly discovery), whereas a DAD-less operation would be a single RA
> message (forgetting the initial MLD 'join').
> 
>> There is one additional reason for the DHCPv6 to be slower.
> 
> One of the reasons DHCPv4/v6 may be slower lies in the discovery phase.
> Every discovery phase takes some time.  Old DHCPv4 implementations take
> too much time, as do old WiFi 'scanning' operations (another discovery).
> 
> Better implementations of the discovery phases take shorter time, yet
> they are extremely lengthy compared to what agreed numbers and multicast
> join/leave operations can achieve.
> 
>> An RA-based protocol interaction may influence host's routing.  A
>> DHCPv6-based interaction today can not influence the host's routing
>> - it was specifically denied any and all involvement into routing.
> [...]
>> FIXME: This section needs further debates, clarifications, and a
>> rewrite.  Discussion welcome.
> 
> There is an ongoing discussion in the DHC WG about this.  Namely about
> routing at DHCP Relay during Prefix Delegation.  Implementations
> consider seriously 'snooping' and adding routing table entries at Relay
> during DHCP operations.  Standards e.g. BBF require a solution to this
> problem.
> 
> There were several drafts and presentations during recent 2-3 years.
> Most recent draft is at
> draft-petrescu-relay-route-pd-problem-00.txt
> 
>> Regarding RA for routing and DHCP for addressing, what people care
>> about is connectivity.  What I need as an operator is a protocol
>> (preferably a single protocol because that is simpler) which will
>> enable my boxes to gain the connectivity they need.  Whether you
>> call this routing or providing a default gateway, I don't much mind.
>> Look, there's too much ideology going on here.  The IETF is being
>> dazzled by the sight of multiple lan segments and multiple egress
>> gateways without realising that these are the minority
>> configuration. All this effort is going into optimising ipv6 address
>> / lan autoconfiguration for these unusual scenarios without heeding
>> the sober reality that most people, service providers and enterprises
>> are only ever going to want to have a single defgw per lan segment,
>> and that by far the most common deployment scenario will be a single
>> lan segment per organisation.
>> 
>> Wireless?  My smartphone already has two radios and a physical
>> interface, connected to multiple providers.  How exactly do you then
>> configure a "single defgw per lan segment" (without draft-troan-
>> homenet-sadr-01)
>> 
>> I'm aware that this viewpoint will be regarded as retrograde, and
>> that a bunch of people on this list will probably sit there, rolling
>> their eyes and thinking: "yeah, and 640k was enough for everyone".
>> Just bear in mind that added complexity is not necessarily a good
>> thing.  The support costs are high and the return on effort is
>> dubious at best.  IOW, the IETF is optimising a corner case.
> 
> This and later paragraphs read as a story I can understand but it would
> need reformulation to become less personal.
> 
> Then...
> 
> In the past we strived to build a table comparing the parameters which
> RA configures vs. the parameters which DHCP configures.  The value was
> in finding which parameters are the exclusive domain of one or the other
> in current RFCs.
> 
> For example, Prefix Delegation is only specified for DHCPv6 (not for
> RA), whereas the MTU parameter, and default router parameters (IP
> address, MAC address) are only for the RA (not for DHCP).
> 
> Alex
> 
> Le 27/11/2013 14:06, Andrew Yourtchenko a écrit :
>> Hello all,
>> 
>> Finally I managed to comb a little bit and finally submit the doc
>> that aims to compare RAs with DHCPv6 which emerged from the
>> discussion on this list a few weeks ago.
>> 
>> I'll be very happy to hear any comments, suggestions, flames, etc.
>> 
>> --a
>> 
>> 
>> p.s. The "realtime changes" repository is at:
>> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the
>> feedback via a pull request :)
>> 
>> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013
>> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko
>> <ayourtch@cisco.com> Subject: New Version Notification for
>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>> 
>> 
>> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>> has been successfully submitted by Andrew Yourtchenko and posted to
>> the IETF repository.
>> 
>> Filename:     draft-yourtchenko-ra-dhcpv6-comparison Revision:
>> 00 Title:         A comparison between the DHCPv6 and RA based host
>> configuration Creation date:     2013-11-27 Group:         Individual
>> Submission Number of pages: 12 URL:
>> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>> 
>> 
>> Status:
>> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison
> Htmlized:
>> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00
>> 
>> 
>> Abstract: This document attempts to make a balanced comparison
>> between the RA- based and DHCPv6-based host configuration mechanisms.
>> It compares the two on different aspects, e.g: underlying media
>> assumptions, coordination, locality, etc.  and highlights the strong
>> and weak sides of both protocols for each scenario.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> The IETF Secretariat _______________________________________________
>> v6ops mailing list v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops