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 protected]> wrote: > 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". > > PPE - ok > Section 1 > > The OSPFv2 specifies a Shortest Path First (SPF) algorithm that > > (same nit about adding "protocol") > > PPE - ok > 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. > > 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:" > Section 4 > > I suggest noting that the (lettered) sub-procedures of step (2) remain > unchanged. > > PPE - The original format of OSPF rfc2328 steps for SPF calculation was kept for clarity. Would a sentence to that effect work? > 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? > 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. > 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". > > 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 > > 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? > > PPE - suggest adding the word " prefix" which was implicit here. > 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.) > > > Let me know if these changes address your comments Padma
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
