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

Andrew Yourtchenko <ayourtch@cisco.com> Tue, 17 December 2013 10:45 UTC

Return-Path: <ayourtch@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 5B5B61ADBCF for <v6ops@ietfa.amsl.com>; Tue, 17 Dec 2013 02:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level:
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 PJaNkrHttwe0 for <v6ops@ietfa.amsl.com>; Tue, 17 Dec 2013 02:45:44 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E98741AE146 for <v6ops@ietf.org>; Tue, 17 Dec 2013 02:45:43 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAjgie002118 for <v6ops@ietf.org>; Tue, 17 Dec 2013 11:45:42 +0100 (CET)
Received: from [10.61.223.174] ([10.61.223.174]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAjbFD010147; Tue, 17 Dec 2013 11:45:38 +0100 (CET)
Date: Tue, 17 Dec 2013 10:45:37 +0000
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@ayourtch-mac
To: Ray Hunter <v6ops@globis.net>
In-Reply-To: <52B001B8.7030602@globis.net>
Message-ID: <alpine.OSX.2.00.1312171018270.80976@ayourtch-mac>
References: <alpine.OSX.2.00.1311271353550.3903@ayourtch-mac> <52B001B8.7030602@globis.net>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: 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: Tue, 17 Dec 2013 10:45:47 -0000

Thanks for the insight!

inline.

On Tue, 17 Dec 2013, Ray Hunter wrote:

> Andrew Yourtchenko wrote:
>> 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
> I think the draft will be useful if
>
> 1) it allows an operator to make an informed choice
>
> 2) it identifies areas for future work
>
> With that in mind
>
> for 1) As a general remark after reading the comments to the list so
> far, there seems to be an underlying assumption that there's only one
> way to run a network, and that the infrastructure stack of Hosts/ LAN /
> MAN/ WAN/ DHCPv6/ DNS/ IPAM / Printers are all run by a single
> authority, and thus integration and change costs are effectively zero.
>
> IMHO "all combinations are possible" as used in an advert by a local
> supermarket. These infrastructure elements are usually run on behalf of
> a single authority in my experience, but if your LAN routers are not run
> by the same people as your IPAM and DNS, you might well want to make
> different trade offs with respect to what information is communicated by
> RA and what by DHCPv6, and what requests are relayed to a central
> instance and what is configured in a distributed manner on the local boxes.
>
> I think the pure technical discussions miss the impact on the management
> model mentioned in 2.10.
>
> I'd like to see an addition of some sample management models, where the
> infrastructure is run by different parties (this is v6ops after all).
> e.g. if you can set up your LAN routers to set up their interfaces using
> PD (with all information loaded from IPAM) plus a couple of DHCPv6 relay
> commands for the rest (also potentially loaded/learned from IPAM) I
> could imagine considerable costs savings in large environments. Whereas
> in a highly distributed environment, IPAM may not even make any sense at
> all, and local configuration via RA and local config files only might be
> extremely useful and cost effective. Provisioning is a major network cost.
>
> However that choice in turn is likely to impact the ease of renumbering
> in the future (a major bugbear of IPv4). It will also impact what
> protocols a travelling end node will have to support (code bloat).

I had just removed the entire management section, so this would be for the 
potential future.

I am welcoming the texts describing the operational models that people use 
which I can include as an issue for now, for later, when the "semantics" 
are done.

>
> 2) I also think the areas of future work would be filled quicker if we
> examine the alternative approaches, and filled in the complete picture.
>
> So I'd suggest we look at the complete end to end picture needed to roll
> out and support the following combinations
>
> a) Central model: everything configured centrally as far as possible,
> with zero configuration information that is likely to change stored
> locally (configure local LAN switch once and forget, plus central IPAM
> DNS etc. for changes)
> You'll then hit the "How does an end node learn a default route?" and
> thus "how does the RA daemon learn it's prefix information?" type questions
> Think Meraki cloud controlled devices.
>
> b) Distributed model: everything configured locally on the local LAN
> switch or router (no IPAM required)
> You'll then hit the "how is DNS updated?" type questions.
>
> c) download model: hosts actively grab an XML file via HTTP for their
> "extended" configuration (or use AD).
>
> d) stand alone (disconnected) model: there is no router.
> You'll then hit the "How do I elect a DNS server?" and "why not use
> zeroconf?" type questions

This looks like two pairs across two independent axis ? (a-b, c-d) ?

Also: if there's no router, there's no communication beyond the link.

>
> There is considerable overlap here with Homenet....... although the
> focus could be specifically on address assignment and the interactions
> between end nodes and routers.

There were two goals:

1) "what are the inherent protocol properties of RA vs. DHCP"
2) "what to extend for new functionality, RA vs. DHCP ?"

With the assumption the (1) would help to understand (2) better. Maybe.

Now, looking at a-d above, I wonder whether the "new functionality" needs 
to be more tightly bound as a prerequisite to even (1).

If I were writing a new app, I'd certainly try to avoid both RA and
DHCP, in lieu of the download or zeroconf. If I am writing the new 
L3 protocol that needs to be provisioned - this is when I would start to 
consider "RA vs. DHCP".

--a

>
> -- 
> Regards,
> RayH
>