[Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10

Tim Chown via Datatracker <noreply@ietf.org> Thu, 07 November 2019 22:21 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7421208B7; Thu, 7 Nov 2019 14:21:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tim Chown via Datatracker <noreply@ietf.org>
To: <ops-dir@ietf.org>
Cc: last-call@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Tim Chown <tim.chown@jisc.ac.uk>
Message-ID: <157316531939.2026.10004843645321945107@ietfa.amsl.com>
Date: Thu, 07 Nov 2019 14:21:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qH6m2rgkNAHHOqyh9mZ4Up0asPI>
Subject: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 22:22:00 -0000

Reviewer: Tim Chown
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The document describes a mechanism by which a node running OSPFv2 can repel
transit traffic if it is on the shortest path (and an alternative path exists -
though this is not wholly clear in the document). It defines a Host-bit (H-bit)
that allows the router to advertise that it is not a transit router, and it
describes the changes needed to support the H-bit within a domain, and
mitigations against potential routing loops.

General comments:

Should the document also state that it updates RFC 2328?

I think the document could be clearer on the behaviour when the H-bit and
MaxLinkMetric are used when there is only one path available, i.e. there is no
redundant / alternative path.  Section 4 of RFC 6987 implies that if there is
only one path the router can still be used as a transit router, by the nature
of the definition of MaxLinkMetric.  The document has 3 or 4 places where it
hints at behaviour, but I think it could be more explicit.

It may be worth explicitly stating that OSPFv3 is not mentioned due to it
having an R-bit defined for indicating whether a node/router can be used for
transit traffic (see Sections 2.7 and A.2 of RFC 5340).

The reasons given in Section 1 for the need for the H-bit are different to
those given in Section 1 of RFC 6987 for the capability.  Should these be more
consistent?   Also, the document later mentions “a router being gracefully
isolated” as a reason, but this is not mentioned in Section 1.

Nits:

In the abstract:
Change
“This document defines a bit (Host-bit)”
to
“This document defines a Host bit (H-bit)”
for consistency
And “is a non-transit router.”” - remove the spurious “.

Section 8:
Where it says “beyond those already known in OSPF”, say OSPFv2.