On Wed, Dec 04, 2019 at 10:22:53AM -0800, Padma Pillay-Esnault wrote: > 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:"
Thanks! > > > 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? 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. > > > > 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. Looks good. > > 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. Thanks! > > > 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 They look good, thanks again. -Ben _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
