Skip to main content

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
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