RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

"BRUNGARD, DEBORAH A" <db3546@att.com> Sat, 24 February 2018 21:07 UTC

Return-Path: <db3546@att.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5903126C3D; Sat, 24 Feb 2018 13:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EGlBAeCg8nOP; Sat, 24 Feb 2018 13:07:45 -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 0A18A124BE8; Sat, 24 Feb 2018 13:07:44 -0800 (PST)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w1OL5HLY012386; Sat, 24 Feb 2018 16:07:40 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2gbeumrjsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Feb 2018 16:07:40 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w1OL7dTQ027389; Sat, 24 Feb 2018 16:07:40 -0500
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w1OL7ZpU027360; Sat, 24 Feb 2018 16:07:35 -0500
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 1940340006B6; Sat, 24 Feb 2018 21:07:35 +0000 (GMT)
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27128.vci.att.com (Service) with ESMTPS id 0303B4000693; Sat, 24 Feb 2018 21:07:35 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.6]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0361.001; Sat, 24 Feb 2018 16:07:34 -0500
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-rtgwg-backoff-algo@ietf.org" <draft-ietf-rtgwg-backoff-algo@ietf.org>, Uma Chunduri <uma.chunduri@huawei.com>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
Thread-Topic: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
Thread-Index: AQHTqp74EopTMk21x0ub2Sen+/QcaqOv7WsAgAQY88A=
Date: Sat, 24 Feb 2018 21:07:34 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C88825014A@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <151916777965.9746.8021764261240149263.idtracker@ietfa.amsl.com> <2C4A7142-1784-4488-BB2D-5CC47E69E958@cisco.com>
In-Reply-To: <2C4A7142-1784-4488-BB2D-5CC47E69E958@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.218.124]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-24_07:, , 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-1802240282
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/uQ9Cg1Y2k23OmmouvTCwyXRB8TA>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2018 21:07:47 -0000

Hi Acee,

Sorry for not responding earlier, I had an unexpected disruption to my schedule these last days.

I was concerned as the document itself says "Optionally, implementations may also offer alternative algorithms." So it is not clear if it is the algorithm or the parameters which are intended PS.

And especially concerning is section 7 on partial deployment. It states the algorithm is only effective if it is deployed on all routers, and partial deployment will increase the frequency and duration of micro-loops. It does go on to say operators have progressively replaced an implementation of a given algorithm by a different one.

If this is to be PS, then you need to provide guidance on how an operator is to do the upgrade to this new algorithm on a network. I understand there are prototype implementations, but I'm concerned on field grade deployments in existing networks.

Thanks,
Deborah

-----Original Message-----
From: Acee Lindem (acee) [mailto:acee@cisco.com] 
Sent: Wednesday, February 21, 2018 7:53 PM
To: BRUNGARD, DEBORAH A <db3546@att.com>om>; The IESG <iesg@ietf.org>
Cc: draft-ietf-rtgwg-backoff-algo@ietf.org; Uma Chunduri <uma.chunduri@huawei.com>om>; rtgwg-chairs@ietf.org; rtgwg@ietf.org
Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

Hi Deborah, 



Given that the goal of RFC 6976 was much more ambitious and the mechanisms are much more complex, I don't think this draft should be put in the same category. 



What we have done is precisely specify a standard algorithm for IGP SPF back-off. When deployed, this standard algorithm will greatly improve (but not eliminate) micro-loops in IGP routing domains currently utilizing disparate SPF back-off algorithms. The problem statement draft best articulates the impact of differing SPF back-off algorithms: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drtgwg-2Dspf-2Duloop-2Dpb-2Dstatement-2D06.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=Vtva23qDNV_XHrGXH4C87wmfZuLcxGEDJAXqVihSSPw&e= . Finally, there have been several prototype implementations validating the algorithm specification's completeness and clarity. 



Thanks,

Acee



    Deborah Brungard has entered the following ballot position for

    draft-ietf-rtgwg-backoff-algo-07: Discuss

    

    When responding, please keep the subject line intact and reply to all

    email addresses included in the To and CC lines. (Feel free to cut this

    introductory paragraph, however.)

    

    

    Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=LvqOOWwzZ-3P6mF9xQUGj2HWklodlOlWO94fprhgwc8&e= 

    for more information about IESG DISCUSS and COMMENT positions.

    

    

    The document, along with other ballot positions, can be found here:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=YnZA5VGqF0T8BAOlFKka0ckWFUhUDHd0sILBbPRRaeU&e= 

    

    

    

    ----------------------------------------------------------------------

    DISCUSS:

    ----------------------------------------------------------------------

    

    While I agree with Alvaro's concerns, my concern is the appropriateness of this document as PS.

    This document should have a similar status as RFC6976 (Informational) which also provided a

    mechanism that prevented transient loops saying "the mechanisms described in this

    document are purely illustrative of the general approach and do not constitute a protocol

    specification". Especially as this document compares itself to RFC6976, saying RFC6976 is a

    "full solution".

    

    With a change of status to Informational, this document would be better

    scoped as providing guidance vs. a specification.