Hi Dhruv, Thanks for the review - I think your comments have improved the document. They are incorporated in the -17 version. > On Jan 4, 2025, at 06:00, Dhruv Dhody via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dhruv Dhody > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-lsvr-applicability-15 > Reviewer: Dhruv Dhody > Review Date: 2025-01-04 > IETF LC End Date: 2024-12-25 > Intended Status: Informational > > ## Summary: > > This document discusses the usage and applicability of BGP Shortest Path First > (BGP-SPF) extensions in the DC networks utilizing Clos or Fat-Tree topologies. > This is an informational document intended to provide a simplified guide for > the deployment of BGP-SPF extensions in DC. > > ## Comments: > > The document is well-written and easy to read, but I have some minor comments > and nits. > > ## Minor Issues: > > - Consider including "BGP" in the title of the document. I agree - I made the title consistent with "BGP Link-State Shortest Path First (SPF) Routing”. > > - Consider rephrasing section 1; the use of "after" to start the 2nd and 3rd > paragraph does not sound right. Agreed. These prepositional phrases have been removed. > > - Figure 1, I dont understand the reason for labeling the servers as > A,O,B,O,Z,O,O,O? Further, it might also be worth to explain the topology in > words clearly marking which nodes belong to which tier as the figure could be > confusing (for example, is Node 3 Tier-1 or 3 could be unclear from just the > figure). I’ve improved the figure and believe I’ve made the tiers evident. > > - Section 4, there is also a longer motivation section (1.2) in > draft-ietf-lsvr-bgp-spf. Should it be referenced here? Reference added. > > - Section 5.1; "The reasons for enabling both SAFIs at the same time is out of > the scope of this document." -- is there a reference where the reason is > listed? Perhaps draft-ietf-lsvr-bgp-spf? This seems like important information > to provide to the reader. Use case for underlay/overlay added. > > - Provide either a small description or a reference for "bi-connected graph" Added a sentence describing context. > > - Consider rephrasing section 5.2.2, it is unclear if this just one possible > heuristic or it is THE mechanism being specified that all implementations > should follow. Added a final paragraph indicating that this isn’t the only possible spare peering heuristic. > > - In Figure 2, should there be a link (~) between Leaf 1 and Leaf 2? Agreed - this is not needed and confusing. It has been removed. > > ## Nits: > > - Expand OAM, LLDP, BFD, IBGP on first use. Expanded based on previous comments in in -16. > > - Section 4; s/prohibits a deployment of/prohibits the deployment of/ Changed. > > - Section 5; s/used by [RFC2328]/used by OSPF [RFC2328]/ Added. > > - Section 5.4; s/accomplished today with using/accomplished today by using/ Changed. > > - Section 5.4; s/could have parameters than/could have more parameters than/ Changed to “different parameters”. > > - Section 8; s/filtered and the abstracted/filtered and abstracted/ Fixed. > > - Section 8; s/if tradition BGP routing/if traditional BGP routing/ Fixed. > > - Various instances of articles (a, an, the) missing. I didn’t see any of these offhand. Note that “policy” in this context can be considered plural. Thanks, Acee > > Thanks! > Dhruv > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
