Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs

"STARK, BARBARA H" <bs7652@att.com> Mon, 05 February 2018 17:11 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 846E71273B1 for <v6ops@ietfa.amsl.com>; Mon, 5 Feb 2018 09:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zWbsWru3oTeD for <v6ops@ietfa.amsl.com>; Mon, 5 Feb 2018 09:11:28 -0800 (PST)
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 9A8361270AB for <v6ops@ietf.org>; Mon, 5 Feb 2018 09:11:28 -0800 (PST)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w15H4vF3025535; Mon, 5 Feb 2018 12:11:23 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2fxsa3ky6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 12:11:23 -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 w15HBMZ1011713; Mon, 5 Feb 2018 12:11:22 -0500
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 w15HBFSc011575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Feb 2018 12:11:17 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 5 Feb 2018 17:11:01 GMT
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 3FE354000368; Mon, 5 Feb 2018 17:11:01 +0000 (GMT)
Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30484.vci.att.com (Service) with ESMTPS id 2C21A4000361; Mon, 5 Feb 2018 17:11:01 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.51]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0361.001; Mon, 5 Feb 2018 12:11:00 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
CC: "7riw77@gmail.com" <7riw77@gmail.com>, David Farmer <farmer@umn.edu>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs
Thread-Index: AQHThAkt88VuzkKF+0q3aAiqoqlIRgJ9OQ9TASu4nfEBwpaRTQKGdYJTAomRt9CiC9Z1cIEc4/sAgBUtWICAAEg5gIAAMvKAgADh2ICAAvjDEIAAZyqA//+xntA=
Date: Mon, 05 Feb 2018 17:10:59 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DD0FB39@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <B7CB2B98-F069-425D-A096-AADA0297B34C@gmail.com> <CAKD1Yr0r=OZKWHatcaV5ZfXUcJhTrzGqnd6wno7SLur9cJzF5w@mail.gmail.com> <066901d385ab$64d663b0$2e832b10$@gmail.com> <CAKD1Yr2GjXKM53rJJwRzX7RyrCG8u+KZ0TTGuFv=NefHsKRxrw@mail.gmail.com> <bb950d32-8d8a-420b-f01a-609f941109af@gmail.com> <CAKD1Yr10o6aqFQ9QWvJdv82gCh7fXzFEcDjZV2beaO_ebLZAig@mail.gmail.com> <058c01d39188$cb3f7630$61be6290$@gmail.com> <c09653f7-6b5b-5fce-a81e-298a38bd747b@gmail.com> <008101d39c3c$430331d0$c9099570$@gmail.com> <CAN-Dau3Tm5yQbz_8qd9gH5Fk3udWfdqJv9Om+WBAjAjUvLOffA@mail.gmail.com> <002701d39c79$d8ead1c0$8ac07540$@gmail.com> <006801d39cea$d1ed5a70$75c80f50$@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DD0F9A6@GAALPA1MSGUSRBF.ITServices.sbc.com> <8395CFA7-D7BA-405F-94C8-3E2406B4D1CF@gmail.com>
In-Reply-To: <8395CFA7-D7BA-405F-94C8-3E2406B4D1CF@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.223.241]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_04:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050215
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/oVz2eqfWTD7Rm4E1ocrvjyFDpM0>
Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs
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: Mon, 05 Feb 2018 17:11:30 -0000

> Thanks for this. It's cogent and to the point.
> 
> I do have a question. The authors are from LinkedIn and Comcast. How
> would you interpret that fact in the context of the facts you point out?

That's for them to say what their motivation is. But Comcast and LinkedIn are both known to be at the forefront of IPv6 deployment. I wouldn't classify LinkedIn as an ISP of any sort or a core/transit network provider or an IXC. If LinkedIn or Comcast thinks there is a need for requirements for data center network routers, that would be interesting to know. Most major data center operators I know have gone to using SDN (with open source router software on commodity hardware). I don't recall having heard Comcast say they need a router requirements document to help with their access/regional network IPv6 deployment (which seems to be doing quite well). I don't know about any internal corporate networks they may have -- which I would classify as "enterprise networks".

Personally, I haven't heard any of the people working on any of my employer's access/regional/core networks asking for a new IETF router requirements document (the IPv6 metrics for wireline and wireless access are looking pretty good with non-IPv6 traffic due to hosts/wireless UEs/retail CE routers and not the network routers, and no issues in the core; router requirements would have no impact on use of 6rd in legacy DSL access). I have not yet noticed IPv6 in the corporate (enterprise) network that I attach to for work. I've also heard from some people who work with enterprise customers that adoption among those customers is a painfully slow crawl.

Clearly, there is a population with a need. If we focus on helping that population, it might be possible to drive results.
Barbara

> > On Feb 5, 2018, at 7:34 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> >
> >>> The primary focus is routers for enterprise or carrier use, however
> >>> most of the features also have broad applicability to all routers.
> >
> > I see a real need for recommendations for enterprise routers. I also believe
> that any attempts to broaden the scope beyond that will both slow down
> producing such recommendations and force the recommendations to be
> watered down to the point whether they are significantly less useful to
> enterprise networks.
> > Here is why I think most other router types either don't need or will ignore
> these recommendations:
> > - CE routers are covered by RFC 7084
> > - telco ISPs aren't asking for this (for their own ISP networks) and
> > tend to use BBF documents; any who are waiting until IETF produces
> > router requirements for them need to reconsider their strategy
> > - cable ISPs aren't asking for this (for their own ISP networks) and
> > tend to use CableLabs docs; any who are waiting until IETF produces
> > router requirements for them need to reconsider their strategy
> > - wireless ISPs aren't asking for this and tend to use 3GPP docs; any
> > who are waiting until IETF produces router requirements for them need
> > to reconsider their strategy
> > - transit/core network providers aren't asking for this and have
> > already got IPv6 running (and if they haven't, there's no excuse,
> > because the equipment is there); they also don't tend to do address
> > assignment (no hosts on those networks) so requirements for DHCPv6 and
> > SLAAC aren't needed; a lot of this equipment is done with SDN now;
> > this is also true of a lot of the "regional network" part of ISP
> > networks
> > - IXCs don't tend to do address assignment and seem to have IPv6 in
> > place; any that don't have IPv6 -- it's not for lack of requirements;
> > a lot of them have gone to SDN
> >
> > As for SDN: If you think an open source project doing SDN code is missing
> some IPv6 functionality, it might be easier to contribute the code, rather than
> write an RFC and see if some random person says "OMG, the IETF is saying
> do this; no-one else is writing this code so I guess I better do it".
> >
> > We need to get enterprises transitioning. Whatever IETF can do to help
> that specific audience would be appreciated.
> > Barbara
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops