[Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-ospfv2-hbit-11: No Objection

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-ospfv2-hbit/



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

Abstract

   The Open Shortest Path First Version 2 (OSPFv2) does not have a
   mechanism for a node to repel transit traffic if it is on the
   shortest path.  This document defines a bit (Host-bit) that enables a

nit: I suggest to add "protocol" after "(OSPFv2)" to match the definite
article "The".

Section 1

   The OSPFv2 specifies a Shortest Path First (SPF) algorithm that

(same nit about adding "protocol")

   This functionality is particularly useful for a number of use cases:

nit: "this functionality" seems to refer to "the SPF algorithm that
identifies transit verticies based on their adjacencies", so I suggest
rewording to "such functionality would be useful" or "A mechanism to
move traffic away from the shortest path" or similar.

Section 4

I suggest noting that the (lettered) sub-procedures of step (2) remain
unchanged.

Section 5

   In normal operation, there is no guarantee that the RI LSA will reach
   all routers in an area in a timely manner, which may result in
   forwarding loops in partial deployments.  For example, if a new
   router joins an area, which previously had only H-bit capable routers
   with H-bit set then it may take some time for the RI to propagate to
   all routers.

It's currently only implicit that this new router does not support the
H-bit; shall we make it explicit?

   o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
      in the area before actively running the modified SPF to account
      for the H-bit in order to verify that all routers are in routing
      capability.  If any router does not advertise the Host Router

nit: the grammar here is a little wonky, particularly for "all routers
are in routing capability" but perhaps also for "to account for the
H-bit".

Section 6

   When calculating the path to an OSPF AS-External-LSA or NSSA-LSA
   [RFC3101] with a Type-2 metric, [...]

nit: is this saying "calculating the path to [an LSA]"?  That's not a
usage I'm familiar with; can the AS-External-LSA or NSSA-LSA really
serve as a destination in this sense?

Section 7

Thank you for phrasing this as "this document requests the IANA to
assign", since until these specific values are officially assigned we
are technically "squatting" on them.  (The respective registration
policies of Standards Action and IETF Review give us pretty good control
that nothing else is going to swoop in on them, though.)