Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers
draft-ietf-lsvr-applicability-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-01-28
|
22 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2025-01-24
|
22 | (System) | RFC Editor state changed to EDIT |
2025-01-24
|
22 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2025-01-24
|
22 | (System) | Announcement was received by RFC Editor |
2025-01-24
|
22 | (System) | IANA Action state changed to In Progress |
2025-01-24
|
22 | Jenny Bui | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-01-24
|
22 | Jenny Bui | IESG has approved the document |
2025-01-24
|
22 | Jenny Bui | Closed "Approve" ballot |
2025-01-24
|
22 | Jenny Bui | Ballot approval text was generated |
2025-01-24
|
22 | (System) | Removed all action holders (IESG state changed) |
2025-01-24
|
22 | Jim Guichard | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2025-01-23
|
22 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-22.txt |
2025-01-23
|
22 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2025-01-23
|
22 | Acee Lindem | Uploaded new revision |
2025-01-22
|
21 | John Scudder | [Ballot comment] Thanks for addressing my DISCUSS points. One nit that arose in the new version, "received by leave nodes” should be “received by leaf … [Ballot comment] Thanks for addressing my DISCUSS points. One nit that arose in the new version, "received by leave nodes” should be “received by leaf nodes”. |
2025-01-22
|
21 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2025-01-19
|
21 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Yaron Sheffer. Sent review to list. |
2025-01-16
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2025-01-16
|
21 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2025-01-16
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-01-16
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2025-01-16
|
21 | Jie Dong | New version available: draft-ietf-lsvr-applicability-21.txt |
2025-01-16
|
21 | Jie Dong | New version accepted (logged-in submitter: Jie Dong) |
2025-01-16
|
21 | Jie Dong | Uploaded new revision |
2025-01-10
|
20 | (System) | Changed action holders to Acee Lindem, Keyur Patel, Jie Dong, Shawn Zandi, Gaurav Dawra (IESG state changed) |
2025-01-10
|
20 | Jim Guichard | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2025-01-09
|
20 | Jenny Bui | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2025-01-08
|
20 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2025-01-08
|
20 | John Scudder | [Ballot discuss] Thanks for your work on this document. It was interesting to review it in conjunction with draft-ietf-lsvr-bgp-spf-44. I have some concerns about it, … [Ballot discuss] Thanks for your work on this document. It was interesting to review it in conjunction with draft-ietf-lsvr-bgp-spf-44. I have some concerns about it, let's discuss. Specifics below. ## DISCUSS ### Section 5.3, aggregation "In Spine/Leaf topologies, it is not necessary to advertise BGP-LS Prefix NLRI received by leaves northbound to the spine nodes. An aggregate route or a default route could suffice." That seems wrong to me. Spines need to know all the topology, they can't default toward the leaves. I can't even guess what you meant here. ### Section 5.4, requirements in an applicability doc? I thought this was a "usage and applicability" document, that was going to explain to me how BGP SPF is used/can be used in data centers. But then I hit this section and it's "requirements", as if the solution isn't done at all, it's still being worked on, and you're not even sure how it's going to work. The final clause really drives that home: Finally, a simple BGP discovery protocol could also be used to establish a multi-hop session with one or more controllers by advertising connectivity to one or more controllers. However, once the multi-hop session traverses multiple nodes, it is bordering a distance-vector routing protocol and possibly this is not a good requirement for the discovery protocol. You don't even know what you want in a discovery protocol (or if you want one at all)? It is fine that you don't know this stuff yet, but I have to ask: is this document ready for publication? Or is the WG still working on the solution and should come back when it's complete? ### Section 5.5.1, you're violating RFC 9552 If IPv6 link-local peering is used, then configuration of IPv6 global addresses is also not required [RFC7404] and these IPv6 link-local addresses must then be advertised in the BGP-LS Link Descriptor IPv6 Address TLV (262) [RFC9552]. RFC 9552 Section 5.2.2 says, IPv4/IPv6 link-local addresses MUST NOT be carried in the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262) as descriptors of a link since they are not considered unique. If you want to violate that, then I think you need to clearly indicate what you're doing, say why it's OK even though RFC 9552 said it wasn't, and get the IDR WG to sign off. ### Section 8, aggregation in a link-state network is scary Real IGPs don't aggregate other than at area boundaries (where they turn into glorified distance-vector protocols). As such, I (a) don't understand what you're doing with the first paragraph and (b) think it's both scary and too vague. |
2025-01-08
|
20 | John Scudder | [Ballot comment] ## COMMENT ### Section 4, severely prohibits "It severely prohibits the deployment of Route Reflectors/Route Controllers as the EBGP sessions are congruent with … [Ballot comment] ## COMMENT ### Section 4, severely prohibits "It severely prohibits the deployment of Route Reflectors/Route Controllers as the EBGP sessions are congruent with the data path." If it "prohibits", it doesn't get any more severe than that, "prohibits" means never. So drop the adverb. On the other hand, maybe you meant "severely impairs" or similar, which would stop short of absolute prohibition. But I think you mean "prohibits". ### Section 5.1 and elsewhere, "BGP-LS SPF" You use the term "BGP-LS SPF" in many places. That term doesn't appear anywhere in draft-ietf-lsvr-bgp-spf-44, it uses "BGP-LS-SPF" (with hyphen) throughout. I guess that's what you mean? ### Section 5.1.1, preference "Normally, the BGP-LS SPF AFI/SAFI is used solely to compute the underlay and is given preference over other AFI/SAFIs." Preference can mean so many things. I am guessing that in this case you mean preference for route selection, but in any case, please be clear. ### Section 5.2 and elsewhere, switch Probably wherever you say "switch" you mean "router"? ### 5.2.2, single layer-3 connection "For northbound sessions, BGP speakers will attempt to maintain two northbound BGP sessions with different switches (in data center fabrics there is normally a single layer-3 connection anyway)." I have no idea what you mean by the comment in the parentheses. Can you help me understand? ### 5.4, session collision "The latter can be used for debugging and to decrease the likelihood of BGP session establishment collisions." First of all, I'm not sure how you'd use it that way. But second, why bother? RFC 4271 has a perfectly serviceable algorithm for resolving session establishment collisions. ### 5.5.1 what kind of interfaces now? For IPv4 address families, IPv6 peering as specified in [RFC8950] can be deployed to avoid configuring IPv4 addresses on BGP- LS SPF router interfaces. What does "BGP-LS SPF" modify? Router? Or interfaces? It might help to just get rid of some adjectives, as in, For IPv4 address families, IPv6 peering as specified in [RFC8950] can be deployed to avoid configuring IPv4 addresses on router interfaces. |
2025-01-08
|
20 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2025-01-08
|
20 | Roman Danyliw | [Ballot comment] Thank you to Mallory Knodel for the GENART review. |
2025-01-08
|
20 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2025-01-08
|
20 | Deb Cooley | [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley |
2025-01-08
|
20 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2025-01-06
|
20 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2025-01-06
|
20 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2025-01-06
|
20 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-20.txt |
2025-01-06
|
20 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2025-01-06
|
20 | Acee Lindem | Uploaded new revision |
2025-01-06
|
19 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-lsvr-applicability-19 CC @evyncke Thank you for the work put into this document. Please find below some … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-lsvr-applicability-19 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Ketan Talaulikar for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Section 1 Please re-expand `BGP-SPF` (as the abstract is not really part of the document). ### Sections 2 & 5 Please use OSPFv3 RFC rather than RFC 2328 for OSPFv2 ;-) ### Section 3 It took me some seconds to realize that the figure is rotated 90° as the more common setting with North = Tier 1 (e.g., as in figure 2). Is it on purpose ? ### Section 4 Suggest moving `Additional motivation for deploying BGP-SPF is included in [I-D.ietf-lsvr-bgp-spf].` at the end of this section and as a paragraph (currently, it seems out of the flow). Should `SPF` be expanded ? ### Section 5.1 Should `SAFI` be expanded ? ### Section 5.2.1 Is it about LAG in `they are often aggregated at the link layer rather than the IP layer` if so, then why not writing it ? Is it `each leaf switch` or "each leaf router" ? ### Section 5.4 As IPv6 RAs announce the link-local IPv6 address, is it a problem ? (normally not, but perhaps worth mentioning ? or adding a reference to section 5.5.1) ### Section 5.5.1 It is quite unusual to have a subsection adding a reference to its parent section as in `as described in Section 5.5, `` Thanks for suggesting RFC 7404 ;-) ### Section 6 `One potential deployment would be the underlay for a Service Provider (SP) backbone` looks weird in a document whose title is `Usage and Applicability of BGP-SPF in Data Centers`... Suggest removing this section. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) |
2025-01-06
|
19 | Éric Vyncke | Ballot comment text updated for Éric Vyncke |
2025-01-06
|
19 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2025-01-06
|
19 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2025-01-06
|
19 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-19.txt |
2025-01-06
|
19 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2025-01-06
|
19 | Acee Lindem | Uploaded new revision |
2025-01-05
|
18 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-18.txt |
2025-01-05
|
18 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2025-01-05
|
18 | Acee Lindem | Uploaded new revision |
2025-01-04
|
17 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-17.txt |
2025-01-04
|
17 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2025-01-04
|
17 | Acee Lindem | Uploaded new revision |
2025-01-04
|
16 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-lsvr-applicability-16 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments … [Ballot comment] # Internet AD comments for draft-ietf-lsvr-applicability-16 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S4 * I'm kind of surprised that there's no mention of nor comparison with draft-ietf-rift-rift, which I thought was aimed at Clos/Fat-Tree deployments. ### S5.5.1 * For IPv6 link-local -only network design, see if RFC 7404 is a useful reference for this document. ## Nits ### S5.4 * "BGP sessions with a ToR device could have parameters than BGP sessions between..." -> "BGP sessions with a ToR device could have different parameters than BGP sessions between..." I suspect. |
2025-01-04
|
16 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2025-01-04
|
16 | Dhruv Dhody | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Dhruv Dhody. Sent review to list. |
2025-01-03
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2025-01-03
|
16 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-16.txt |
2025-01-03
|
16 | (System) | New version approved |
2025-01-03
|
16 | (System) | Request for posting confirmation emailed to previous authors: Acee Lindem , Gaurav Dawra , Jie Dong , Keyur Patel , Shawn Zandi |
2025-01-03
|
16 | Acee Lindem | Uploaded new revision |
2025-01-02
|
16 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2024-12-28
|
15 | Cindy Morgan | Placed on agenda for telechat - 2025-01-09 |
2024-12-27
|
15 | Carlos Pignataro | Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': Previous review of -09 (diff) : Ready by Ron Bonica |
2024-12-27
|
15 | Mallory Knodel | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Mallory Knodel. Sent review to list. |
2024-12-26
|
15 | Jim Guichard | Ballot has been issued |
2024-12-26
|
15 | Jim Guichard | [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard |
2024-12-26
|
15 | Jim Guichard | Created "Approve" ballot |
2024-12-26
|
15 | Jim Guichard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-12-26
|
15 | Jim Guichard | Ballot writeup was changed |
2024-12-25
|
15 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-12-19
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Mallory Knodel |
2024-12-13
|
15 | Daniam Henriques | Request for Last Call review by RTGDIR is assigned to Dhruv Dhody |
2024-12-12
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2024-12-12
|
15 | David Dong | IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lsvr-applicability-15, which is currently in Last Call, and has the following comments: We understand that this … IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-lsvr-applicability-15, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-12-12
|
15 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2024-12-11
|
15 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-12-11
|
15 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-12-25): From: The IESG To: IETF-Announce CC: Gunter Van de Velde , aretana.ietf@gmail.com, draft-ietf-lsvr-applicability@ietf.org, … The following Last Call announcement was sent out (ends 2024-12-25): From: The IESG To: IETF-Announce CC: Gunter Van de Velde , aretana.ietf@gmail.com, draft-ietf-lsvr-applicability@ietf.org, james.n.guichard@futurewei.com, ketant.ietf@gmail.com, lsvr-chairs@ietf.org, lsvr@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Usage and Applicability of Link State Vector Routing in Data Centers) to Informational RFC The IESG has received a request from the Link State Vector Routing WG (lsvr) to consider the following document: - 'Usage and Applicability of Link State Vector Routing in Data Centers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-12-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses the usage and applicability of BGP Link-State Shortest Path First (BGP-SPF) extensions in data center networks utilizing Clos or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of BGP-SPF extensions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ No IPR declarations have been submitted directly on this I-D. |
2024-12-11
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-12-11
|
15 | Jim Guichard | Requested Last Call review by RTGDIR |
2024-12-11
|
15 | Jim Guichard | Requested Last Call review by OPSDIR |
2024-12-11
|
15 | Jim Guichard | Requested Last Call review by SECDIR |
2024-12-11
|
15 | Jim Guichard | Last call was requested |
2024-12-11
|
15 | Jim Guichard | Last call announcement was generated |
2024-12-11
|
15 | Jim Guichard | Ballot approval text was generated |
2024-12-11
|
15 | Jim Guichard | Ballot writeup was generated |
2024-12-11
|
15 | Jim Guichard | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-12-11
|
15 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2024-12-11
|
15 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-12-11
|
15 | Jie Dong | New version available: draft-ietf-lsvr-applicability-15.txt |
2024-12-11
|
15 | (System) | New version approved |
2024-12-11
|
15 | (System) | Request for posting confirmation emailed to previous authors: Acee Lindem , Gaurav Dawra , Jie Dong , Keyur Patel , Shawn Zandi |
2024-12-11
|
15 | Jie Dong | Uploaded new revision |
2024-12-02
|
14 | (System) | Changed action holders to Acee Lindem, Keyur Patel, Jie Dong, Shawn Zandi, Gaurav Dawra (IESG state changed) |
2024-12-02
|
14 | Jim Guichard | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2024-12-02
|
14 | Jim Guichard | AD review of draft-ietf-lsvr-applicability-14 === https://mailarchive.ietf.org/arch/msg/lsvr/JZqRLKQHby8gRzJn3tBnpntlIcA/ === |
2024-11-26
|
14 | Jim Guichard | IESG state changed to AD Evaluation from Publication Requested |
2024-11-12
|
14 | Ketan Talaulikar | Added to session: IETF-121: lsvr Thu-1530 |
2024-11-08
|
14 | Ketan Talaulikar | Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach … Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has gone through 2 WGLCs: - 1st concluded in May 2020 - 2nd concluded in Nov 2024 (the current one) The document and its first WGLC had good participation from the WG. However the second one was much less. Taken together the document does represent broad agreement in the WG. 2) Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4) For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? This is an informational draft the implementations exist for the protocol specification that is documented in draft-ietf-lsvr-bgp-spf Additional Reviews 5) Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes. Since this is related to BGP extension, the document has been cross-posted to the IDR WG for reviews during the 2nd WGLC. 6) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. not applicable 7) If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? not applicable - note that the corresponding YANG module is being worked on in a separate document by the WG 8) Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. Has been run clean through idnits; others don't apply Document Shepherd Checks 9) Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes 10) Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? RTGDIR and OPSDIR reviews have happened 11) What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Informational - this is reflected in the datatracker. Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This draft describes how such infrastructure can apply BGP-SPF specification (draft-ietf-lsvr-bgp-spf). This draft is Informational and discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. 12) Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR has been declared on this document. Yes - all authors have responded to the previous and the latest IPR poll during the WGLC. 13) Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes and not applicable 14) Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) None 15) Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. None 16) List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None 17) Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. None 18) Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? None 19) Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20) Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). No IANA considerations apply 21) List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No IANA considerations apply |
2024-11-08
|
14 | Ketan Talaulikar | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-11-08
|
14 | Ketan Talaulikar | IESG state changed to Publication Requested from I-D Exists |
2024-11-08
|
14 | Ketan Talaulikar | Document is now in IESG state Publication Requested |
2024-11-08
|
14 | Ketan Talaulikar | Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach … Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has gone through 2 WGLCs: - 1st concluded in May 2020 - 2nd concluded in Nov 2024 (the current one) The document and its first WGLC had good participation from the WG. However the second one was much less. Taken together the document does represent broad agreement in the WG. 2) Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4) For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? This is an informational draft the implementations exist for the protocol specification that is documented in draft-ietf-lsvr-bgp-spf Additional Reviews 5) Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes. Since this is related to BGP extension, the document has been cross-posted to the IDR WG for reviews during the 2nd WGLC. 6) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. not applicable 7) If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? not applicable - note that the corresponding YANG module is being worked on in a separate document by the WG 8) Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. Has been run clean through idnits; others don't apply Document Shepherd Checks 9) Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes 10) Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? RTGDIR and OPSDIR reviews have happened 11) What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Informational - this is reflected in the datatracker. Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This draft describes how such infrastructure can apply BGP-SPF specification (draft-ietf-lsvr-bgp-spf). This draft is Informational and discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. 12) Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR has been declared on this document. Yes - all authors have responded to the previous and the latest IPR poll during the WGLC. 13) Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes and not applicable 14) Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) None 15) Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. None 16) List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None 17) Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. None 18) Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? None 19) Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20) Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). No IANA considerations apply 21) List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No IANA considerations apply |
2024-11-08
|
14 | Ketan Talaulikar | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-11-06
|
14 | Ketan Talaulikar | Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach … Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has gone through multiple WGLCs: - 1st concluded in May 2020 - 2nd concluded in Nov 2024 (the current one) The document and its first WGLC had good participation from the WG. However the second one was much less. Taken together the document does represent broad agreement in the WG. 2) Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4) For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? This is an informational draft the implementations exist for the protocol specification that is documented in draft-ietf-lsvr-bgp-spf Additional Reviews 5) Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Yes. Since this is related to BGP extension, the document has been cross-posted to the IDR WG for reviews during the 2nd WGLC. 6) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. not applicable 7) If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? not applicable - note that the corresponding YANG module is being worked on in a separate document by the WG 8) Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. Has been run clean through idnits; others don't apply Document Shepherd Checks 9) Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes 10) Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? RTGDIR and OPSDIR reviews have happened 11) What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Informational - this is reflected in the datatracker. Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This draft describes how such infrastructure can apply BGP-SPF specification (draft-ietf-lsvr-bgp-spf). This draft is Informational and discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. 12) Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No IPR has been declared on this document. Yes - all authors have responded to the previous and the latest IPR poll during the WGLC. 13) Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes and not applicable 14) Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) None 15) Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. None 16) List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None 17) Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. None 18) Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? None 19) Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20) Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). No IANA considerations apply 21) List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No IANA considerations apply |
2024-11-05
|
14 | Jie Dong | New version available: draft-ietf-lsvr-applicability-14.txt |
2024-11-05
|
14 | Jie Dong | New version accepted (logged-in submitter: Jie Dong) |
2024-11-05
|
14 | Jie Dong | Uploaded new revision |
2024-10-22
|
13 | Ketan Talaulikar | Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com, ketant.ietf@gmail.com, james.n.guichard@futurewei.com from Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com … Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com, ketant.ietf@gmail.com, james.n.guichard@futurewei.com from Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com, ketant.ietf@gmail.com |
2024-10-22
|
13 | Ketan Talaulikar | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2024-10-22
|
13 | Ketan Talaulikar | IETF WG state changed to In WG Last Call from WG Document |
2024-10-21
|
13 | Jie Dong | New version available: draft-ietf-lsvr-applicability-13.txt |
2024-10-21
|
13 | (System) | New version approved |
2024-10-21
|
13 | (System) | Request for posting confirmation emailed to previous authors: Acee Lindem , Gaurav Dawra , Keyur Patel , Shawn Zandi , lsvr-chairs@ietf.org |
2024-10-21
|
13 | Jie Dong | Uploaded new revision |
2024-10-08
|
12 | Cindy Morgan | IESG state changed to I-D Exists from Dead |
2024-10-08
|
12 | Jim Guichard | Changed consensus to Yes from Unknown |
2024-10-08
|
12 | Jim Guichard | Changed action holders to Jim Guichard |
2024-10-08
|
12 | Ketan Talaulikar | Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com, ketant.ietf@gmail.com from Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com because the … Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com, ketant.ietf@gmail.com from Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com because the document shepherd was set |
2024-10-08
|
12 | Ketan Talaulikar | Document shepherd changed to Ketan Talaulikar |
2024-08-16
|
12 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-12.txt |
2024-08-16
|
12 | (System) | New version approved |
2024-08-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: Acee Lindem , Gaurav Dawra , Keyur Patel , Shawn Zandi |
2024-08-16
|
12 | Acee Lindem | Uploaded new revision |
2024-08-15
|
11 | (System) | Document has expired |
2024-08-15
|
11 | (System) | Removed all action holders (IESG state changed) |
2024-08-15
|
11 | (System) | IESG state changed to Dead from I-D Exists |
2024-02-12
|
11 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-11.txt |
2024-02-12
|
11 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2024-02-12
|
11 | Acee Lindem | Uploaded new revision |
2023-08-21
|
10 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-10.txt |
2023-08-21
|
10 | (System) | New version approved |
2023-08-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: Acee Lindem , Gaurav Dawra , Keyur Patel , Shawn Zandi |
2023-08-21
|
10 | Acee Lindem | Uploaded new revision |
2023-05-22
|
09 | Gunter Van de Velde | WGLC yielded constructive feedback. Revised document expected. |
2023-05-22
|
09 | Gunter Van de Velde | Tag Revised I-D Needed - Issue raised by WGLC set. |
2023-05-22
|
09 | Gunter Van de Velde | IETF WG state changed to WG Document from In WG Last Call |
2023-04-20
|
09 | Gunter Van de Velde | 2nd WGLC after receiving updates based upon AD and WG feedbacks. OPS-DIR and RTG-DIR reviews completed on the -09 document |
2023-04-20
|
09 | Gunter Van de Velde | Tag Revised I-D Needed - Issue raised by AD cleared. |
2023-04-20
|
09 | Gunter Van de Velde | IETF WG state changed to In WG Last Call from WG Document |
2023-04-14
|
09 | Stig Venaas | Request for Early review by RTGDIR Completed: Ready. Reviewer: Stig Venaas. Sent review to list. |
2023-04-12
|
09 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2023-04-12
|
09 | Jim Guichard | IESG state changed to I-D Exists from Dead |
2023-04-12
|
09 | Jim Guichard | Shepherding AD changed to Jim Guichard |
2023-04-10
|
09 | Ron Bonica | Request for Early review by OPSDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list. |
2023-03-29
|
09 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Stig Venaas |
2023-03-28
|
09 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Ron Bonica |
2023-03-27
|
09 | Gunter Van de Velde | Requested Early review by RTGDIR |
2023-03-27
|
09 | Gunter Van de Velde | Requested Early review by OPSDIR |
2023-02-20
|
09 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-09.txt |
2023-02-20
|
09 | Acee Lindem | New version accepted (logged-in submitter: Acee Lindem) |
2023-02-20
|
09 | Acee Lindem | Uploaded new revision |
2021-09-26
|
08 | (System) | Document has expired |
2021-03-25
|
08 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-08.txt |
2021-03-25
|
08 | (System) | New version accepted (logged-in submitter: Acee Lindem) |
2021-03-25
|
08 | Acee Lindem | Uploaded new revision |
2021-03-25
|
07 | (System) | Document has expired |
2021-03-25
|
07 | (System) | IESG state changed to Dead from AD is watching |
2020-12-10
|
07 | Alvaro Retana | Tag Revised I-D Needed - Issue raised by AD set. Tag Revised I-D Needed cleared. |
2020-12-10
|
07 | Alvaro Retana | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2020-12-10
|
07 | Alvaro Retana | Given that this document depends heavily on the BGP SPF specification, and that the spec requires a significant amount of work, I am returning both … Given that this document depends heavily on the BGP SPF specification, and that the spec requires a significant amount of work, I am returning both documents to the WG. |
2020-12-10
|
07 | Alvaro Retana | IESG state changed to AD is watching::Revised I-D Needed from AD Evaluation |
2020-12-10
|
07 | Alvaro Retana | === AD Review of draft-ietf-lsvr-applicability-07 === https://mailarchive.ietf.org/arch/msg/lsvr/wSalwvCwgY93lAaitw4h2o6Kfmo/ |
2020-09-21
|
07 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-07.txt |
2020-09-21
|
07 | (System) | New version accepted (logged-in submitter: Acee Lindem) |
2020-09-21
|
07 | Acee Lindem | Uploaded new revision |
2020-09-18
|
06 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2020-09-18
|
06 | Alvaro Retana | Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com>, aretana.ietf@gmail.com from Gunter Van de Velde <gunter.van_de_velde@nokia.com> |
2020-07-26
|
06 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-06.txt |
2020-07-26
|
06 | (System) | New version accepted (logged-in submitter: Acee Lindem) |
2020-07-26
|
06 | Acee Lindem | Uploaded new revision |
2020-05-26
|
05 | Gunter Van de Velde | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This draft describes how such infrastructure can apply BGP-SPF (draft-ietf-lsvr-bgp-spf-09) technology. This draft is Informational and discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. Working Group Summary: The LSVR WG enjoyed a turbulent startup period. The IDR WG and LSR WG handle routing for interdomain and intradomain, while LSVR is using foundational technology of both BGP and SPF based routing protocols. The IETF face-2-face meetings avoided timing overlap to allow IDR and LSR WG participants to voice the depths of their experience and technology authority. This contributed to develop and provide guidelines and applicability information for BGP-SPF based LSVR documented by draft-ietf-lsvr-applicability. Draft draft-ietf-lsvr-applicability-05 is target informational draft. The draft went through few iterations being presented at the face-2-face IETF LSVR WG meetings and volunteer review cycles that have been tracked within the WG email list. The draft did not go through any early review cycles. Document Quality: Implementations of the LSVR BGP-SPF exist, however this draft is about how to apply BGP-SPF LSVR technology Personnel: Document Shepherd: Gunter Van de Velde Responsible Area Director: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been presented few times during the IETF WG meetings and the document went through WGLC. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LSVR WG is a working group that exists of senior member from both IDR and LSR working groups. Feedback and reviews have been executed, and been incorporated by the document authors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This document explain how to use BGP-SPF LSVR technology. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded for no IPR awareness. No WG member responded with IPR awarenes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document was produced to explain how BGP-SPF is expected to be applied in MSDC environments. It was created by the lead authors of the BGP-SPF LSVR draft, and while reviewed by the working group, it does reflect for the most the opinion of those lead BGP-SPF authors. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No Appeal threatenings (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Only idnit was an reference to an older version (draft-ietf-lsvr-bgp-spf-07) of the bgp-spf draft, which was caused by a last minute update of that draft to be release -08. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. YANG document is pending creation for LSVR BGP-SPF (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? This draft document depends normative upon [I-D.ietf-lsvr-bgp-spf]. This applicability draft explains how to apply ietf-lsvr-bgp-spf in a network environment (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This draft suggest no IANA changes. No changes are required (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. None (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? YANG will be handled in a different LSVR YANG document for BGP-SPF |
2020-05-26
|
05 | Gunter Van de Velde | Responsible AD changed to Alvaro Retana |
2020-05-26
|
05 | Gunter Van de Velde | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-05-26
|
05 | Gunter Van de Velde | IESG state changed to Publication Requested from I-D Exists |
2020-05-26
|
05 | Gunter Van de Velde | IESG process started in state Publication Requested |
2020-05-26
|
05 | Gunter Van de Velde | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This draft describes how such infrastructure can apply BGP-SPF (draft-ietf-lsvr-bgp-spf-09) technology. This draft is Informational and discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. Working Group Summary: The LSVR WG enjoyed a turbulent startup period. The IDR WG and LSR WG handle routing for interdomain and intradomain, while LSVR is using foundational technology of both BGP and SPF based routing protocols. The IETF face-2-face meetings avoided timing overlap to allow IDR and LSR WG participants to voice the depths of their experience and technology authority. This contributed to develop and provide guidelines and applicability information for BGP-SPF based LSVR documented by draft-ietf-lsvr-applicability. Draft draft-ietf-lsvr-applicability-05 is target informational draft. The draft went through few iterations being presented at the face-2-face IETF LSVR WG meetings and volunteer review cycles that have been tracked within the WG email list. The draft did not go through any early review cycles. Document Quality: Implementations of the LSVR BGP-SPF exist, however this draft is about how to apply BGP-SPF LSVR technology Personnel: Document Shepherd: Gunter Van de Velde Responsible Area Director: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been presented few times during the IETF WG meetings and the document went through WGLC. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LSVR WG is a working group that exists of senior member from both IDR and LSR working groups. Feedback and reviews have been executed, and been incorporated by the document authors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This document explain how to use BGP-SPF LSVR technology. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors responded for no IPR awareness. No WG member responded with IPR awarenes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document was produced to explain how BGP-SPF is expected to be applied in MSDC environments. It was created by the lead authors of the BGP-SPF LSVR draft, and while reviewed by the working group, it does reflect for the most the opinion of those lead BGP-SPF authors. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No Appeal threatenings (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Only idnit was an reference to an older version (draft-ietf-lsvr-bgp-spf-07) of the bgp-spf draft, which was caused by a last minute update of that draft to be release -08. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. YANG document is pending creation for LSVR BGP-SPF (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? This draft document depends normative upon [I-D.ietf-lsvr-bgp-spf]. This applicability draft explains how to apply ietf-lsvr-bgp-spf in a network environment (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This draft suggest no IANA changes. No changes are required (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. None (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? YANG will be handled in a different LSVR YANG document for BGP-SPF |
2020-05-26
|
05 | Gunter Van de Velde | Intended Status changed to Informational from None |
2020-05-15
|
05 | Gunter Van de Velde | Notification list changed to Gunter Van de Velde <gunter.van_de_velde@nokia.com> |
2020-05-15
|
05 | Gunter Van de Velde | Document shepherd changed to Gunter Van de Velde |
2020-05-06
|
05 | Gunter Van de Velde | Waiting for IPR awareness from all authors |
2020-05-06
|
05 | Gunter Van de Velde | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2020-03-24
|
05 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-05.txt |
2020-03-24
|
05 | (System) | New version approved |
2020-03-24
|
05 | (System) | Request for posting confirmation emailed to previous authors: Shawn Zandi , Gaurav Dawra , Acee Lindem , Keyur Patel |
2020-03-24
|
05 | Acee Lindem | Uploaded new revision |
2019-11-02
|
04 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-04.txt |
2019-11-02
|
04 | (System) | New version accepted (logged-in submitter: Acee Lindem) |
2019-11-02
|
04 | Acee Lindem | Uploaded new revision |
2019-11-02
|
03 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-03.txt |
2019-11-02
|
03 | (System) | New version accepted (logged-in submitter: Acee Lindem) |
2019-11-02
|
03 | Acee Lindem | Uploaded new revision |
2019-11-02
|
02 | (System) | Document has expired |
2019-05-01
|
02 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-02.txt |
2019-05-01
|
02 | (System) | New version approved |
2019-05-01
|
02 | (System) | Request for posting confirmation emailed to previous authors: Gaurav Dawra , Shawn Zandi , Acee Lindem , Keyur Patel |
2019-05-01
|
02 | Acee Lindem | Uploaded new revision |
2019-04-25
|
01 | (System) | Document has expired |
2018-10-22
|
01 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-01.txt |
2018-10-22
|
01 | (System) | New version approved |
2018-10-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Gaurav Dawra , Shawn Zandi , Acee Lindem , Keyur Patel |
2018-10-22
|
01 | Acee Lindem | Uploaded new revision |
2018-08-27
|
00 | Gunter Van de Velde | Correcting Meta-data |
2018-08-27
|
00 | Gunter Van de Velde | This document now replaces draft-keyupate-lsvr-applicability instead of None |
2018-07-26
|
00 | Acee Lindem | New version available: draft-ietf-lsvr-applicability-00.txt |
2018-07-26
|
00 | (System) | WG -00 approved |
2018-07-25
|
00 | Acee Lindem | Set submitter to "Acee Lindem ", replaces to (none) and sent approval email to group chairs: lsvr-chairs@ietf.org |
2018-07-25
|
00 | Acee Lindem | Uploaded new revision |