[OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

Deborah Brungard <db3546@att.com> Tue, 23 January 2018 17:01 UTC

Return-Path: <db3546@att.com>
X-Original-To: ospf@ietf.org
Delivered-To: ospf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D512127137; Tue, 23 Jan 2018 09:01:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Deborah Brungard <db3546@att.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ospf-link-overload@ietf.org, Acee Lindem <acee@cisco.com>, ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151672688324.13994.3394246547043297427.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 09:01:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/lqNDiVfrC_BsvDzB1veN3mxD0w4>
Subject: [OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2018 17:01:23 -0000

Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-link-overload-13: 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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document is defining a MAX-TE-METRIC of 0xfffffffe. But RFC5817 defined
0xffffffff to be used for graceful shutdown. I noted an email exchange between
the author and Acee on this where Acee raised the question why RFC5817's value
was not used. Shraddha replied "We can if we have the Working Group Consensus".
There was no further discussion.

This document was not shared with teas which is responsible for TE (or ccamp
which was originally responsible for RFC5817).

Either this value needs to be changed to RFC5817's value or this TE metric
needs to be removed from this document until agreement with TEAS.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found the title of section 7.2 "Controller Based Traffic Engineering
Deployments" confusing as it only is describing a controller controlling a
path. It is not "TE" in the IETF sense e.g. TE signaling. It would be much less
confusing if say "Controller Based Deployments" and "satisfying the traffic
engineering constraints"/s/"satisfying the constraints". Especially as for TE,
procedures already do exist.  I noted in the introduction you did reference
RFC5817 MPLS Graceful Shutdown on the procedures when doing a graceful shutdown
of a TE link.