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 protected]> wrote: > > 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 protected]> 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
