Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

"STARK, BARBARA H" <bs7652@att.com> Tue, 21 February 2017 19:20 UTC

Return-Path: <bs7652@att.com>
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 31FE112943F for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2017 11:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.488
X-Spam-Level:
X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 94OIqLsRhXT2 for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2017 11:20:23 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 072E112711D for <v6ops@ietf.org>; Tue, 21 Feb 2017 11:20:23 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v1LJJXTl016254; Tue, 21 Feb 2017 14:20:12 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 28rukx00r7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Feb 2017 14:20:12 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1LJKB0A029793; Tue, 21 Feb 2017 14:20:11 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1LJK8Hg029778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 14:20:08 -0500
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 21 Feb 2017 19:19:48 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.76]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 14:19:47 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>
Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt
Thread-Index: AQHSjErmrfnJlR21KESvvZHHQ3NOt6Fzvufg
Date: Tue, 21 Feb 2017 19:19:47 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DAC7459@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <148763027040.25952.5914924936449771028.idtracker@ietfa.amsl.com> <692043A0-04F2-46EA-84D2-D4964E925C6B@consulintel.es> <B32D8BA9-0C0D-4576-9B7A-C08044A7433A@ripe.net> <CAAedzxpJB+rfDzm8H0ZpoYQymeqSjw1hdZnjFSNU24pyXoM+pA@mail.gmail.com> <7D4321A8-BC93-4C40-B61C-193959662246@consulintel.es> <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com>
In-Reply-To: <0E28D1F7-B250-482A-AB41-B76265CA19B5@gmx.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.251.237]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-21_16:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702210178
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/np14X_M6ONqsVdX3-HAGMuIj1fI>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 21 Feb 2017 19:20:24 -0000

Some of my thoughts on things that have been said ...

> ... vendors need a very strong signal here, otherwise, many of them (and this is happening), are reading actual 7084 and only reacting to implement those transition technologies with specific firmware versions for “very big” customers which will buy several hundred thousand units in one shot.

I'm not aware of any vendors *who sell to ISPs* and use RFC 7084 as the basis for what they put in their firmware. Most such vendors use BBF TR-124 or CableLabs CE Router specs. As an author of RFC 7084, I really saw this RFC as targeting the retail vendors. That was my reason for working on it. If all I needed was requirements for vendors to ISPs, BBF TR-124 would have been sufficient. 
I do sympathize with the small ISPs. I just wonder if this is the right way to do it. I wonder if a completely new (not modified RFC 7084) draft whose intent is clearly stated as being to specify additional transition functionality needed by many small ISPs might be a better approach. It might be good to strategize on the best way to achieve this desired goal, rather than first discussing what requirements are MUST/SHOULD/MAY. And also agree on this as the goal of a new draft.
It may be more effective to have a small targeted draft that says "do mandatory dual stack parts of RFC 7084; and here is additional transition technology that many small ISPs need to be able to get from their vendors". 
We would need a number of smaller ISPs to join in support, if it's to be successful. And the set of requirements definitely need to be limited.
If that were the focus of the draft, I wouldn't bother including 6rd at all.

> And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see push back from them on downgrading 6rd to MAY (though perhaps they don't much care, idk).

At this point, for me, it's a "don't care". When deployment first started, there was a distinct percentage of AT&T customers who had no (and no option for) AT&T-provided CE Router (because of a legacy broadband architecture in the southeast US). As I mentioned, RFC 7084 was about retail and not ISP-procured CE routers -- so having 6rd in retail routers provided these customers (including me) a way to get 6rd up and running on AT&T. Over the past 1.5 years, AT&T has put FTTH in place for almost all (or maybe by now all) those customers, which means AT&T CE routers are available (and for FTTH, required). You can't even find the 6rd configuration info on the AT&T website anymore. [You can still find the info where other people have posted it. Just not from AT&T.] 
I do have my own CE router behind the AT&T CE router. The AT&T CE router provides a /64 from the 6rd /60 via IA_PD to my router. So it looks to my router like native IPv6.
AT&T configured and enabled 6rd, LAN-side SLAAC, and LAN-side DHCPv6 IA_PD in the AT&T CE Router, without my doing anything.

Barbara