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

[Padma Pillay-Esnault <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
>
> PPE - See below for the whole paragraph change.


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

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

PPE - ok

>
>    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?
>
>
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