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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 04 Dec 2019 12:47:27 -0800

Barry Leiba 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:
----------------------------------------------------------------------

I'm going to complain about some wording in Section 5 that Ben already called
out, but I'll try to put in some specific suggestions for corrections here:

   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.

This wording makes it sound exactly the opposite of what you mean, that if the
RI LSA *does* reach all routers in a timely manner it can cause forwarding
loops.  I suggest this:

NEW
   In normal operation, it is possible that the RI LSA will fail to
   reach all routers in an area in a timely manner.  That can result
   in forwarding loops in partial deployments.
END

   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.

First, change "area, which" to "area that" (no comma).  That fixes a usage
problem.

But second, Ben and I are both unsure whether you mean that the new router does
or doesn't support the H bit, or whether it matters.  Maybe the right approach
here is to say a little more about what happens.  Something like this (adjust
as needed to make it correct):

NEW
   For example, if a new
   router joins an area that 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.  While it is propagating, the area as a whole is unsure of
   the status of the new router, and that can cause <what problem?>
END

   o  All routers, with the H-bit set, MUST advertise all of the
      router's non-stub links with a metric equal to MaxLinkMetric

Both commas need to be removed here.

   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.

This is very awkwardly worded and is really hard to decipher.  I *think* you
mean to say this:

NEW
   o  All routers supporting the H-Bit MUST check the RI LSAs of all
      nodes in the area to verify that all nodes support the H-Bit before
      actively using the H-Bit feature.
END

Did I get that right?

---

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

Hi Barry

Thank you for your review

See below PPE for my comments

On Wed, Dec 4, 2019 at 12:47 PM Barry Leiba via Datatracker <
[email-masked]> wrote:

> PPE - See below for the whole paragraph change.

>    the status of the new router, and that can cause <what problem?>
PPE - I see what you mean.
See below combining your suggestion and the one I made to Ben earlier.

Suggested NEW (whole paragraph):
In normal operation, it is possible that the RI LSA will fail to reach all
routers in an area in a timely manner.  For example, if a new router
without H-bit support joins an area that 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. While it is propagating, the routers in the area will
gradually detect the presence of a router not supporting the capability and
revert back to normal SPF calculation. During the propagation time, the
area as a whole is unsure of the status of the new router, and that can
cause temporary transient loops.
 END

> Both commas need to be removed here.

PPE - ok

> Did I get that right?
PPE - Yes you did. I will adopt the suggestion above. It is close to what I
suggested to Ben earlier.

Let me know if this addresses all your comments

Padma

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 Dec 2019 08:44:42 -0500

Thanks, Padma... the new paragraph now seems completely clear to me!
Thanks for the work on this.

Barry

On Thu, Dec 5, 2019 at 1:03 AM Padma Pillay-Esnault
<[email-masked]> wrote:
> On Wed, Dec 4, 2019 at 12:47 PM Barry Leiba via Datatracker <[email-masked]> wrote:
>>
> In normal operation, it is possible that the RI LSA will fail to reach all routers in an area in a timely manner.  For example, if a new router without H-bit support joins an area that 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. While it is propagating, the routers in the area will gradually detect the presence of a router not supporting the capability and revert back to normal SPF calculation. During the propagation time, the area as a whole is unsure of the status of the new router, and that can cause temporary transient loops.
>  END
>
> PPE - Yes you did. I will adopt the suggestion above. It is close to what I suggested to Ben earlier.
>