IETF Logo Mail Archive

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

"STARK, BARBARA H" <bs7652@att.com> Wed, 12 April 2017 12:47 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 839B412945F for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 05:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.401
X-Spam-Level:
X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 3Bgh8QUsJkP7 for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 05:47:40 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 3247B126C2F for <v6ops@ietf.org>; Wed, 12 Apr 2017 05:47:40 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CCjHfn038311; Wed, 12 Apr 2017 08:47:31 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 29sjnrmrrg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 08:47:31 -0400
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 v3CClUDu012527; Wed, 12 Apr 2017 08:47:30 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CClM4P012341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 08:47:24 -0400
Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 12:47:11 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 08:47:11 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "otroan@employees.org" <otroan@employees.org>, "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgP//1q0g
Date: Wed, 12 Apr 2017 12:47:11 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19475@GAALPA1MSGUSRBF.ITServices.sbc.com>
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>
In-Reply-To: <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.164.19]
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-04-12_09:, , 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-1702020001 definitions=main-1704120106
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JAxJlhQylumNTWHx9ZzWVJdBf4k>
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 12:47:41 -0000

> Which is a bit ironic with regards to 6RD which is one of the few mechanisms
> with real deployment, as in millions and millions of users.

The reason I've said I have no problem with backing off 6rd in this document is because I see this document as primarily driving retail devices. The only successful deployments I'm aware of rely on ISP-procured, supplied, and managed devices. No change to 6rd requirements is happening in BBF TR-124.

I have serious doubts that any transition mechanism can be successful if the customer must take any action, whatsoever, to specifically enable it.

Which means I think dual stack is the only scenario it is reasonable to require in retail routers. All retail router implementations I've seen of transition mechanisms require users to (1) have purposefully sought out a router that supports IPv6, (2) know they need a router that supports a specific transition technology, (3) have carefully researched specifically which routers support that particular transition technology (because it won't be listed on the packaging), and (4) enable the transition technology.

Because this customer behavior is so unlikely, it's irrelevant whether or not a retail router supports 6rd. 
In fact, any transition technology that does not ship enabled, simultaneous with dual stack, is irrelevant in retail devices.
Barbara

v2.23.0 | Report a Bug | By Email