IETF Logo Mail Archive

Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 12 April 2017 13:03 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B603D12945B for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 06:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level:
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 w9bjkRr3N45C for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 06:03:45 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E10B1316BE for <v6ops@ietf.org>; Wed, 12 Apr 2017 06:03:45 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 205CBA2; Wed, 12 Apr 2017 15:03:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492002223; bh=gNNL+TWFdG74v/N6XA75W8NkLGIKnBLVhGVzLIxJ4BE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BR9FQ8uC83fsJMw15lDH4cH6LzdlwxinqFmrBf9eg3LpjJjWLonNVyiljX/zIpr3h azh1l6ey7KBzGtSyDR8AyYDyaWsmG2Zer9gKrI7ZeoXPpVv7/goJBL9sdcGodKK0HU GIrZP5q+D2iIKP0InhgPvLzGbQJPCf/+iJgiF+u4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1D2D388; Wed, 12 Apr 2017 15:03:43 +0200 (CEST)
Date: Wed, 12 Apr 2017 15:03:43 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "STARK, BARBARA H" <bs7652@att.com>
cc: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com>
Message-ID: <alpine.DEB.2.02.1704121456550.27978@uplift.swm.pp.se>
References: <D8F5C737-B01A-4EC8-9175-C4921C0CD69F@consulintel.es> <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3t-E7wZRc3MB6MuaarsW9CXGT58>
Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 12 Apr 2017 13:03:48 -0000

On Wed, 12 Apr 2017, STARK, BARBARA H wrote:

> In fact, any transition technology that does not ship enabled, simultaneous with dual stack, is irrelevant in retail devices.

I know of ISPs who send DHCP option 212 to (some) customers. Their IPv6 
enablement rate seems to hover around 1%.

So there seems to be devices out there that support 6RD out of the box, 
but they're such a small minority that I agree that this IPv6 "rollout" 
can't be counted as "successful".

My view on 7084 is that it's a "laundry list", which ISPs can use to 
assist them in successfully procuring residential gateways. So I find it 
useful that it contains lots of stuff, but then perhaps the title 
shouldn't be "basic requirements" anymore, but perhaps something else.

Oles point on it becoming quite extensive is valid. Perhaps we should 
re-focus it to be a document that says "if you want to support X, do 
REQ1-REQ9". I still think it's good input to both people procuring 
gateways, and people implementing gateways. Not all have the resources to 
create that 5000+ lines of requirements whenever they procure a new 
gateway, or large enough that they would get any attention from vendors 
even if they had such a list.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email