Skip to main content

Last Call Review of draft-ietf-ospf-ospfv2-hbit-10
review-ietf-ospf-ospfv2-hbit-10-opsdir-lc-chown-2019-11-07-00

Request Review of draft-ietf-ospf-ospfv2-hbit
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-11-07
Requested 2019-10-24
Authors Keyur Patel , Padma Pillay-Esnault , Manish Bhardwaj , Serpil Bayraktar
I-D last updated 2019-11-07
Completed reviews Rtgdir Last Call review of -09 by He Jia (diff)
Genart Last Call review of -10 by Mohit Sethi (diff)
Tsvart Last Call review of -10 by Kyle Rose (diff)
Opsdir Last Call review of -10 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Request Last Call review on draft-ietf-ospf-ospfv2-hbit by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/P88EhPs8chRhr2vcmpeE6CkK5JE
Reviewed revision 10 (document currently at 12)
Result Has nits
Completed 2019-11-07
review-ietf-ospf-ospfv2-hbit-10-opsdir-lc-chown-2019-11-07-00
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.