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

"STARK, BARBARA H" <bs7652@att.com> Wed, 12 April 2017 17:45 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 3836312EB25 for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 10:45:31 -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 J7YrPSHWb8GD for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 10:45:29 -0700 (PDT)
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 C110212960D for <v6ops@ietf.org>; Wed, 12 Apr 2017 10:45:29 -0700 (PDT)
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 v3CHZ52Y025248; Wed, 12 Apr 2017 13:45:22 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 29sr34f0vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 13:45:21 -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 v3CHjKOk003537; Wed, 12 Apr 2017 13:45:20 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3CHjBFB003422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 13:45:13 -0400
Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 12 Apr 2017 17:44:58 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.165]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 13:44:57 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
Thread-Index: AQHSstX9/aA+q42Pz0u3Y/nN6XijSKHBvWsAgAACzQCAABQWgIAAMIOAgAAEPYD//76fsIAAUwEA///ZnIA=
Date: Wed, 12 Apr 2017 17:44:56 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@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> <CAD6AjGQyatWEOxCpnOn8H+SxG=BWM=cBPaXoON6vA7dj7TNqOQ@mail.gmail.com> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <E181152D-C33F-418A-85BC-4F7829BEE16F@consulintel.es>
In-Reply-To: <E181152D-C33F-418A-85BC-4F7829BEE16F@consulintel.es>
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_13:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120144
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HgOU2MIJ3zHgzvWfC-WKn4w7QTI>
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 17:45:31 -0000

> What I’m saying is that it makes sense to have a single transition mechanism
> (if it is possible, and actually IT IS with 464XLAT) in both kind of networks.

464XLAT is not useful to me. It is not used in any of the networks of my employer. Therefore, it will not be requested in any RFP that I help author, nor will it be required (MUST) by any document referenced by an RFP that I help author. If it magically appears in CE routers without getting in my way, then I won't mind it being there.

-------- snip -----------

> Despite that, I think and it has been said by real operators in this list a few
> months ago, they actually use RFC7048 for their RFQs to vendors, and they
> need support of not just 6rd and DS-lite as we have today. Some of them
> mention specifically lw4o6, 464XLAT and MAP.

RFC 7084 is a mandatory requirement of BBF TR-124, which my company uses for its RFPs. Since my RFPs will not ever require (MUST) 464XLAT, if 7084-bis were to make it a MUST requirement, then 7084-bis would be useless to me as a reference and I would have to ensure 7084-bis was not a requirement in TR-124. And as someone who's written a lot of CE router RFPs, I know for a fact that it is not at all difficult to say "Req1: Do all mandatory requirements of RFC 7084-bis." "Req2: Do 464XLAT as described in RFC 7084-bis."

To be clear: I do not object to the current language of "SHOULD" for 464XLAT. I object to the proposal that it become "MUST".
While I'm at it, I also object to the current language that "If 6rd is implemented, 6in4 MUST be supported as well."  This statement will make the document useless for me as a RFP reference (directly or indirectly), because I will not be requiring 6in4 in my CE routers.

If you want IETF to produce a CE router profile that is just intended to be useful for some operators, please don't call it 7084-bis or have it obsolete 7084. Make it something else (not 7084-bis). A 7084-bis that mandates (MUST) any particular transition technology other than the one deployed in my network is unacceptable to me. And that includes mandating a technology not deployed in my network, just because it implements one that is deployed.

For this document to be a true replacement of RFC 7084, it MUST NOT introduce any "MUST" requirements that an operator currently using RFC 7084 (directly or indirectly) does not want in their CE router.
7084-bis MUST NOT interfere with, place undue burden on, or add cost to existing deployments and the CE routers used in those existing deployments.
Barbara