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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 03 Dec 2019 17:45:31 -0800

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.)

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 4 Dec 2019 10:22:53 -0800

Hi Ben

Thanks for your thorough review.

See below PPE for my comments

On Tue, Dec 3, 2019 at 5:45 PM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> PPE - ok

> PPE - ok

> PPE - ok will change as you suggest

Suggested NEW:
"A mechanism to move traffic away from the shortest path is particularly
useful for a number of use cases:"

> PPE - The original format of OSPF rfc2328 steps for SPF calculation was
kept for clarity. Would a sentence to that effect work?

> H-bit; shall we make it explicit?

PPE - ok

Suggested NEW:
 If a new router without H-bit support 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.

> PPE -  agree

Suggested NEW:
All routers supporting H-Bit MUST check all the RI LSAs of nodes in the
area before actively
running the modified SPF in order to verify that all routers in the area
support the H-bit capability.

Section 6
> PPE - suggest adding the word " prefix" which was implicit here.

> that nothing else is going to swoop in on them, though.)
Let me know if these changes address your comments

Padma

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Dec 2019 12:45:29 -0800

> useful for a number of use cases:"

Thanks!

> kept for clarity. Would a sentence to that effect work?

I think so.  Basically, if a reader treats "step (2)" as including the
lettered sub-procedures, then our replacement version has stripped off all
the sub-procedures and not replaced them.  So we need to tell the reader
that we don't mean to include the sub-procedures in what is being replaced.

> support the H-bit capability.

Looks good.

> > PPE - suggest adding the word " prefix" which was implicit here.

Thanks!

> Let me know if these changes address your comments

They look good, thanks again.

-Ben