[Lsvr] AD Review of draft-ietf-lsvr-applicability-07

[Alvaro Retana <[e-mail]>]

Dear authors:

I just finished reading this document.  As the base specification,
this document also needs more work.  I have some initial comments, and
then specifics in-line below.



(1) Currently, this document reads mostly as "using BGP SPF instead of
what is described in rfc7938", instead of the expected general "using
BGP SPF in a DC".

Not only is the eBGP-based model in rfc7938 just one of many that
could be considered in a DC, but the protocol was selected and the
design developed relying heavily on the characteristics of BGP as a
protocol.  BGP SPF and BGP are *not* the same protocol and don't have
the same characteristics.  A simple example: §5.2.1-5.2.2/rfc7938
describe considerations and a sample ASN scheme based on the
well-known behavior of the AS_PATH.  To contrast, the BGP SPF spec
says that "any attributes that would influence the Decision process
defined in [RFC4271]...are ignored" (§5.1), and there's no mention of
the AS_PATH.  IOW, the considerations from rfc7938, and §6.3 in this
document don't seem to directly match.  [I know that the base spec is
being worked and this point may change; but for now, there is no
normative behavior to stand on.]

Instead of trying to replace rfc7938, please focus on describing how
BGP SPF (specifically draft-ietf-lsvr-bgp-spf) can be used in a DC and
the related operational considerations.

To be clear, referencing rfc7938 is not a bad thing -- but do it in an
Informative way, as an example...not as the guide for deploying BGP
SPF.


(2) It would be very nice, as part of describing the use (without
depending so heavily on rfc7938), if the descriptions included
topology figures for reference.  I know that ASCII-art is not the
best/easiest, but luckily xmltorfc v3 let's you also include SVG
drawings.


(3) There are some sections that don't belong in a "this is how you
use BGP SPF" document.  For example, the justification for BGP SPF and
requirements for future work.  I included specific comments in-line,
but in general, those sections should be removed.


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.

Thanks!

Alvaro.

P.S.  I'm not sure if this review will be fully received by all
mailers.  Please check the archive.  I also put an "[End of Review]"
indicator.


[Line numbers from idnits.]


...
11	  Usage and Applicability of Link State Vector Routing in Data Centers

[] While I personally like the term LSVR more than BGP SPF, the
protocol spec doesn't use LSVR anywhere.  This whole document should
be consistent with it in relation to all the terminology (not just
LSVR vs BGP SPF).  I am not going to repeat this comment everywhere;
please update all the instances in line with the spec.


...
84	1.  Introduction
...
90	   After describing the deployment scenario, Section 5 will describe the
91	   reasons for BGP modifications for such deployments.

[major] As mentioned in I-D.ietf-lsvr-bgp-spf: what is specified is a
new link-state protocol...not just BGP modifications.  IOW, the
motivation (if it was needed) should be about the need for a
link-state protocol based on the BGP transport, and not about
modifying BGP.


...
98	2.  Requirements Language

100	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
101	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
102	   "OPTIONAL" in this document are to be interpreted as described in BCP
103	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
104	   capitals, as shown here.

[major] There's only one place where an rfc2119 keyword is used...and
it doesn't belong in this draft.  I don't think we need this
boilerplate.


106	3.  Recommended Reading

108	   This document assumes knowledge of existing data center networks and
109	   data center network topologies [CLOS].  This document also assumes
110	   knowledge of data center routing protocols like BGP [RFC4271], BGP-
111	   SPF [I-D.ietf-lsvr-bgp-spf], OSPF [RFC2328], as well as, data center
112	   OAM protocols like LLDP [RFC4957] and BFD [RFC5580].

[major] "assumes knowledge of...[CLOS]"  This reference makes the CLOS
document a Normative reference because it "must be read to understand
or implement the technology in the new RFC" [1].  While this shouldn't
be a big issue, I couldn't find a place where the document is freely
available (I did a quick 1-minute search) -- that is an issue!

It seems to me that the contents of this document don't require all
the information in [CLOS].  Consider either (1) finding a link to a
freely available reference, or, (2) include a figure and description
of a general topology that can be used as reference (and mention
[CLOS] as an additional resource).  Note that the description in
rfc7938 could also be another informative reference.  My personal
preference would be #2.

[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/


[minor] "assumes knowledge of data center routing protocols like BGP
[RFC4271], BGP-SPF [I-D.ietf-lsvr-bgp-spf], OSPF [RFC2328]"  Isn't
knowing about BGP SPF enough?  If not, then the references to
rfc4271/rfc2328 should be Normative.


[major] Why does the reader need knowledge of LLDP?  It is not
mentioned anywhere else.


[minor] s/BFD [RFC5580]/BFD [RFC5880]


[major] Why does the reader need knowledge of BFD?  Note that the BGP
SPF spec should be treating BFD as an example, at best.


114	4.  Common Deployment Scenario

116	   Within a Data Center, servers are commonly interconnected the CLOS
117	   topology [CLOS].  The CLOS topology is fully non-blocking and the
118	   topology is realized using Equal Cost Multi-Path (ECMP).  In a CLOS
119	   topology, the minimum number of parallel paths between two servers is
120	   determined by the width of a tier-1 stage as shown in the figure 1.

[nit] s/interconnected the CLOS topology/interconnected using a CLOS topology


[nit] s/topology is fully non-blocking and the topology is
realized/topology is fully non-blocking and is realized


122	   The following example illustrates multi-stage CLOS topology.

[nit] s/illustrates multi-stage/illustrates a multi-stage


...
149	5.  Justification for BGP SPF Extension

[] This section basically says that BGP converges slower than BGP SPF.
That is not a glowing justification to develop a new protocol when
others (traditional link-state protocols, for example) would have
similar characteristics.

Having said that, I don't think it is the job of this document to
justify the existence of BGP SPF -- but just to tell the reader how it
applies to a DC.


...
171	6.  LSVR Applicability to CLOS Networks

173	   With the BGP SPF extensions [I-D.ietf-lsvr-bgp-spf], the BGP best-
174	   path computation and route computation are replaced with OSPF-like
175	   algorithms [RFC2328] both to determine whether an BGP-LS SPF NLRI has
176	   changed and needs to be re-advertised and to compute the BGP routes.
177	   These modifications will significantly improve convergence of the
178	   underlay while affording the operational benefits of a single routing
179	   protocol [RFC7938].

[minor] s/OSPF-like algorithms [RFC2328]/an SPF algorithm


[minor] s/BGP routes/BGP SPF routes


[major] "will significantly improve convergence of the underlay while
affording the operational benefits"   This sounds like nice text for a
marketing brochure.  This document should not be a place to put down
other solutions, and much less to do so without substantiation.  I'm
not asking for tests to show faster convergence (not needed!), just
that the text stay focused on the use of BGP SPF in a DC (not how
other protocols do it or not).


[] "single routing protocol [RFC7938]."  I-D.ietf-lsvr-bgp-spf is not
clear about the use (or not) of multiple AFI/SAFI pairs in the same
peering session.  That is not an issue for this document -- just
pointing at it here so we don't forget to remain consistent.


181	   Data center controllers typically require visibility to the BGP
182	   topology to compute traffic-engineered paths.  These controllers
183	   learn the topology and other relevant information via the BGP-LS
184	   address family [RFC7752] which is totally independent of the underlay
185	   address families (usually IPv4/IPv6 unicast).  Furthermore, in
186	   traditional BGP underlays, all the BGP routers will need to advertise
187	   their BGP-LS information independently.  With the BGP SPF extensions,
188	   controllers can learn the topology using the same BGP advertisements
189	   used to compute the underlay routes.  Furthermore, these data center
190	   controllers can avail the convergence advantages of the BGP SPF
191	   extensions.  The placement of controllers can be outside of the
192	   forwarding path or within the forwarding path.

[nit] s/BGP topology/network topology


[minor] "all the BGP routers will need to advertise their BGP-LS
information independently"  Please add an Informative reference to how
that is done.


[nit] s/BGP advertisements/advertisements


[] "these data center controllers can avail the convergence advantages
of the BGP SPF extensions"  Another nice piece of marketing.  Note
that if each node independently advertises BGP-LS information then
there is no propagation/convergence delay.  In the case of BGP SPF, if
the controller is listening at a specific point in the topology, then
there is propagation delay.


194	   Alternatively, as each and every router in the BGP SPF domain will
195	   have a complete view of the topology, the operator can also choose to
196	   configure BGP sessions in hop-by-hop peering model described in
197	   [RFC7938] along with BFD [RFC5580].  In doing so, while the hop-by-
198	   hop peering model lacks the inherent benefits of the controller-based
199	   model, BGP updates need not be serialized by BGP best-path algorithm
200	   in either of these models.  This helps overall network convergence.

[] This paragraph seems to mix BGP SPF and "normal" BGP peering ala
rfc7938.  I don't follow what the point it -- I'm lost.


202	6.1.  Usage of BGP-LS SPF SAFI

204	   The BGP SPF extensions [I-D.ietf-lsvr-bgp-spf] define a new BGP-LS
205	   SPF SAFI for announcement of BGP SPF link-state.  The NLRI format and
206	   its associated attributes follow the format of BGP-LS for node, link,
207	   and prefix announcements.  Whether the peering model within a CLOS
208	   follows hop-by-hop peering described in [RFC7938] or any controller-
209	   based or route-reflector peering, an operator can exchange BGP SPF
210	   SAFI routes over the BGP peering by simply configuring BGP SPF SAFI
211	   between the necessary BGP speakers.

[] Here again there's a mix between rfc7938 and BGP SPF -- what am I missing?

[major] Route-reflectors don't exist in BGP SPF -- at last not in the
same manner as they do in "normal" BGP.


213	   The BGP-LS SPF SAFI can also co-exist with BGP IP Unicast SAFI which
214	   could exchange overlapping IP routes.  The routes received by these
215	   SAFIs are evaluated, stored, and announced independently according to
216	   the rules of [RFC4760].  The tie-breaking of route installation is a
217	   matter of the local policies and preferences of the network operator.

[major] Co-existence.  The BGP SPF specification is not clear about that.


[minor] "routes...are evaluated, stored, and announced...according to
the rules of [RFC4760]"   s/rfc4760/rfc4271


[minor] "tie-breaking...is a matter of the local policies and
preferences"  True.  This phrase is true regardless of where other
routing information was learned from (including local routes), right?
It feels as if the only case being addressed is one where BGP/BGP SPF
are used for the over/underlay, and not the general case -- maybe the
general case is the one with BGP overlay...describe that (from
scratch) instead of trying to replace a point solution.


219	   Finally, as the BGP SPF peering is done following the procedures
220	   described in [RFC4271], all the existing transport security
221	   mechanisms including [RFC5925] are available for the BGP-LS SPF SAFI.

[major] "peering is done following...[RFC4271]...security mechanisms
including [RFC5925] are available"  This is not accurate because
rfc4271 requires MD5, not TCP-AO.  Also, note that
I-D.ietf-lsvr-bgp-spf doesn't say anything about authentication,
relying on what is defined in rfc4271.

While I have no issues with using TCP-AO, this is not the document to
suggest changes to rfc4271.

This piece of text makes an interesting point (not sure if it was mean
that way) when it points out that TCP-AO is "available [specifically]
for the BGP-LS SPF SAFI".  The interesting part is of course that TCP
authentication is shared by whatever BGP is carrying.  If the BGP SPF
sessions are dedicated to it (i.e. no other AFI/SAFI is negotiated),
then there's no reason why a different authentication mechanism can't
be used.  As I mentioned in my review of the BGP SPF spec, I would
like to see a requirement for isolating the BGP SPF sessions (similar
to rfc7752bis) -- personal opinion, of course.

The other reason for trying to isolate the session is the probable
existence of latency sensitive needs in a datacenter.  Maybe even
going as far as configuring different parameters for the TCP session.


223	6.1.1.  Relationship to Other BGP AFI/SAFI Tuples

225	   Normally, the BGP-LS AFI/SAFI is used solely to compute the underlay
226	   and is given preference over other AFI/SAFIs.  Other BGP SAFIs, e.g.,
227	   IPv6/IPv6 Unicast VPN would use the BGP-SPF computed routes for next
228	   hop resolution.  However, if BGP-LS NLRI is also being advertised for
229	   controller consumption, there is no need to replicate the Node, Link,
230	   and Prefix NLRI in BGP-NLRI.  Rather, additional NLRI attributes can
231	   be advertised in the BGP-LS SPF AFI/SAFI as required (e.g., BGP-LS TE
232	   metric extensions [RFC8571] and BGP-LS segment routing extensions
233	   [I-D.ietf-idr-bgp-ls-segment-routing-ext]).

[major] "BGP-LS AFI/SAFI...is given preference over other AFI/SAFIs"
Preference where?  How?


[major] "...if BGP-LS NLRI is also being advertised for controller consumption,
there is no need to replicate the Node, Link, and Prefix NLRI in BGP-NLRI.
Rather, additional NLRI attributes can be advertised in the BGP-LS SPF AFI/SAFI
as required..."

It is not clear to me which of these two cases you're illustrating
here -- whichever it is, please find a clearer way to explain:

(1) A controller is receiving BGP-LS, and can learn additional details
by listening to BGP SPF (as already suggested in §6).  Why wouldn't
that additional information already be in BGP-LS?  Where is the BGP-LS
information coming from?

(2) A router (not a controller) can use the BGP-LS information
(complemented by additional details carried in BGP SPF).  Again, where
is the BGP-LS information coming from?  Why wouldn't the additional
information be carried by BGP-LS?  If the NLRI information is carried
in BGP-LS (and is to be used in the SPF computation), how is it
validated?


235	6.2.  Peering Models

237	   As previously stated, BGP SPF can be deployed using the existing
238	   peering model where there is a single-hop BGP session on each and
239	   every link in the data center fabric [RFC7938].  This provides for
240	   both the advertisement of routes and the determination of link and
241	   neighboring switch availability.  With BGP SPF, the underlay will
242	   converge faster due to changes to the decision process that will
243	   allow NLRI changes to be advertised faster after detecting a change.

[minor] "provides for both the advertisement of routes and the
determination of link and neighboring switch availability"   What does
this mean?


[] "the underlay will converge faster"  Marketing...


245	6.2.1.  Sparse Peering Model

247	   Alternately, BFD [RFC5580] can be used to swiftly determine the
248	   availability of links and the BGP peering model can be significantly
249	   sparser than the data center fabric.  BGP SPF sessions only need to
250	   be established with enough peers to provide a bi-connected graph.  If
251	   IEBGP is used, then the BGP routers at tier N-1 will act as route-
252	   reflectors for the routers at tier N.

[nit] s/Alternately, BFD/BFD


[minor] "bi-connected graph"  Put a forward reference to §6.2.2,


[major] "IEBGP"   Where is this defined?  The BGP SPF spec doesn't mention it...


254	   The obvious usage of sparse peering is to avoid parallel BGP sessions
255	   on links between the same two switches in the data center fabric.
256	   However, this use case is not very useful since parallel layer-3
257	   links between the same two BGP routers are rare in CLOS or Fat-Tree
258	   topologies.  Additionally, when there are multiple links, they are
259	   often aggregated at the link layer rather than the IP layer.  Two
260	   more interesting scenarios are described below.

[minor] "multiple links, they are often aggregated at the link layer"
I'm not sure if you mean that the link information can be advertised
as a single link.  Where is that covered?  I don't recall the topic of
link aggregation in the BGP SPF spec.


262	   In current data center topologies, there is often a very dense mesh
263	   of links between levels, e.g., leaf and spine, providing 32-way,
264	   64-way, or more Equal-Cost Multi-Path (ECMP) paths.  In these
265	   topologies, it is desirable not to have a BGP session on every link
266	   and techniques such as the one described in Section 6.2.2 can be used
267	   establish sessions on some subset of northbound links.  For example,
268	   in a Spine-Leaf topology, each leaf switch would only peer with a
269	   subset of the spines dependent on the flooding redundancy required to
270	   be reasonably certain that every node within the BGP-LS SPF routing
271	   domain has the complete topology.

[nit] "In current data center topologies..."  A drawing is worth a
thousand words.  Maybe refer to Figure 1 so the reader doesn't have to
make assumptions about what "current" is.


[nit] "be reasonably certain"  That is not enough.


273	   Alternately, controller-based data center topologies are envisioned
274	   where BGP speakers within the data center only establish BGP sessions
275	   with two or more controllers.  In these topologies, fabric nodes
276	   below the first tier (using [RFC7938] hierarchy) will establish BGP
277	   multi-hop sessions with the controllers.  For the multi-hop sessions,
278	   determining the route to the controllers without depending on BGP
279	   would need to be through some other means beyond the scope of this
280	   document.  However, the BGP discovery mechanisms described in
281	   Section 6.5 would be one possibility.

[nit] "first tier (using [RFC7938] hierarchy)"  Using a reference in
this document would be better.


[minor] "route to the controllers"  There is plenty of literature (I
think even some IRTF documents) that deal with the potential issues
with multi-hop, controller based deployments.  Convergence is one of
those issues.  I would like to then see considerations related to the
selection of a peering model: reasons, pros, cons, etc.


283	6.2.2.  Bi-Connected Graph Heuristic

285	   With this heuristic, discovery of BGP peers is assumed, e.g., as
286	   described in Section 6.5.  Additionally, it assumed that the
287	   direction of the peering can be ascertained.  In the context of a
288	   data center fabric, direction is either northbound (toward the
289	   spine), southbound (toward the Top-Of-Rack (TOR) switches) or east-
290	   west (same level in hierarchy.  The determination of the direction is
291	   beyond the scope of this document.  However, it would be reasonable
292	   to assume a technique where the TOR switches can be identified and
293	   the number of hops to the TOR is used to determine the direction.

[nit] s/it assumed/it is assumed


[nit] s/(same level in hierarchy/(same level in hierarchy)


[major] §6.1.1 explains the sparse peering model; the deployment
depends on establishing a bi-connected graph, which depends on both
discovery and the "direction of the peering".  *But*, determining the
direction is out of scope, and discovery is at this point wishful
thinking (from a specification point of view).  IOW, there's no real
explanation of the heuristic.  Also, the BGP SPF spec doesn't cover
either.


295	   In this heuristic, BGP speakers allow passive session establishment
296	   for southbound BGP sessions.  For northbound sessions, BGP speakers
297	   will attempt to maintain two northbound BGP sessions with different
298	   switches (in data center fabrics there is normally a single layer-3
299	   connection anyway).  For east-west sessions, passive BGP session
300	   establishment is allowed.  However, BGP speaker will never actively
301	   establish an east-west BGP session unless it cannot establish two
302	   northbound BGP sessions.

[major] "passive session establishment"   I'm assuming that this
refers to the PassiveTcpEstablishment session attribute from the FSM.
If so, please be specific and point to rfc4271.


[major] This paragraph describes, at a high level, the dynamic
behavior of the peers, but it is not clear how the behavior is
achieved: if automatic, assuming that the direction of the peering is
known, or if there's a configuration expectation to (at least)
indicate the active/passive state of the sessions.


304	6.3.  BGP Spine/Leaf Topology Policy

306	   One of the advantages of using BGP SPF as the underlay protocol is
307	   that BGP policy can be applied at any level.  For example, depending
308	   upon the topology, it may be possible to aggregate prefix
309	   advertisements using existing BGP policy.  In Spine/Leaf topologies,
310	   it is not necessary to advertise BGP-LS NLRI received by leaves
311	   northbound to the spine nodes at the level above.  If a common AS is
312	   used for the spine nodes, this can easily be accomplished with EBGP
313	   and a simple policy to filter advertisements from the leaves to the
314	   spine if the first AS in the AS path is the spine AS.

[major] Yes, "BGP policy can be applied at any level".  However, just
like with mesh-groups in OSPF/ISIS this type of flooding control
mechanism requires careful consideration: filter too much and backup
flooding paths may be lost, filter too little and achieve no
advantage.  The example given (the leaves don't send received routes
up) is straight forward.  Given that that is only an example (not the
only recommendation), I would like to see operational considerations
for the general case.


[major] "aggregate prefix advertisements"  I don't see any mention of
aggregation in the BGP SPF spec.  Maybe by "aggregation" you mean
filtering, or possibly limiting flooding, or...


[minor] "If a common AS is used for the spine nodes..."  What about
the general case?  Is using a common ASN for the spines (or per level)
a recommendation for BGP SPF in a DC, or just an example?


[nit] s/BGP-LS NLRI/BGP SPF NLRI


[minor] "...filter advertisements from the leaves to the spine if the
first AS in the AS path is the spine AS."  The BGP SPF spec says that
the attributes are ignored -- I would then assume that the AS_PATH is
not validated (or used), or is it?


...
319	                +--------+    +--------+             +--------+
320	    AS 64512    |        |    |        |             |        |
321	    for Spine   | Spine 1+----+ Spine 2+- ......... -+ Spine N|
322	    Nodes at    |        |    |        |             |        |
323	    this Level  +-+-+-+-++    ++-+-+-+-+             +-+-+-+-++
324	           +------+ | | |      | | | |                 | | | |
325	           |  +-----|-|-|------+ | | |                 | | | |
326	           |  |  +--|-|-|--------+-|-|-----------------+ | | |
327	           |  |  |  | | |    +---+ | |                   | | |
328	           |  |  |  | | |    |  +--|-|-------------------+ | |
329	           |  |  |  | | |    |  |  | |              +------+ +----+
330	           |  |  |  | | |    |  |  | +--------------|----------+  |
331	           |  |  |  | | |    |  |  +-------------+  |          |  |
332	           |  |  |  | | +----|--|----------------|--|--------+ |  |
333	           |  |  |  | +------|--|--------------+ |  |        | |  |
334	           |  |  |  +------+ |  |              | |  |        | |  |
335	          ++--+--++      +-+-+--++            ++-+--+-+     ++-+--+-+
336	          | Leaf 1|~~~~~~| Leaf 2|  ........  | Leaf X|     | Leaf Y|
337	          +-------+      +-------+            +-------+     +-------+

[nit] Is that squiggly line between Leaf 1 and Leaf 2 meant to be a
link between them?  If so, then they will be transit for each
other...is that what you meant?


339	                   Figure 2: Spine/Leaf Topology Policy

341	6.4.  BGP Peer Discovery Requirements

[major] Peer Discovery is not covered in the BGP SPF spec.  Why are
requirements included here?

[] I didn't include comments on the requirements.


...
386	6.5.1.  BGP Peer Discovery Alternatives

[major] This subject is speculative at this point.  As you start
saying: "peer discovery is not part of [I-D.ietf-lsvr-bgp-spf]".

388	   While BGP peer discovery is not part of [I-D.ietf-lsvr-bgp-spf],
389	   there are, at least, three proposals for BGP peer discovery.  At
390	   least one of these mechanisms will be adopted and will be applicable
391	   to deployments other than the data center.  It is strongly
392	   RECOMMENDED that the accepted mechanism be used in conjunction with
393	   BGP SPF in data centers.  The BGP discovery mechanism should
394	   discovery both peer addresses and endpoints for BFD discovery.
395	   Additionally, it would be great if there were a heuristic for
396	   determining whether the peer is at a tier above or below the
397	   discovering BGP speaker (refer to Section 6.2.2).


...
403	6.5.2.  BGP IPv6 Simplified Peering

405	   In order to conserve IPv4 address space and simplify operations, BGP-
406	   LS SPF routers in CLOS/Fat-Tree deployments can use IPv6 addresses as
407	   peer address.  For IPv4 address families, IPv6 peering as specified
408	   in [RFC5549] can be deployed to avoid configuring IPv4 addresses on
409	   BGP-LS SPF router interfaces.  When this is done, dynamic discovery
410	   mechanisms, as described in Section 6.5, can used to learn the global
411	   or link-local IPv6 peer addresses and IPv4 addresses need not be
412	   configured on these interfaces.  If IPv6 link-local peering is used,
413	   then configuration of IPv6 global addresses is also not required and
414	   these IPv6 link-local addresses must then be advertised in the BGP-LS
415	   Link Descriptor IPv6 Address TLV (262) [RFC7752].

[major] "as specified in [RFC5549]"  This is not covered in the BGP SPF spec.


417	6.5.3.  BGP-LS SPF Topology Visibility for Management

[minor] This sub-section doesn't seem to belong in §6.5: BGP Peer Discovery.


419	   Irrespective of whether or not BGP-LS SPF is used for route
420	   calculation, the BGP-LS SPF route advertisements can be used to
421	   periodically construct the CLOS/FAT Tree topology.  This is
422	   especially useful in deployments where an IGP is not used and the
423	   base BGP-LS routes [RFC7752] are not available.  The resultant
424	   topology visibility can then be used for troubleshooting and
425	   consistency checking.  This would normally be done on a central
426	   controller or other management tool which could also be used for
427	   fabric data path verification.  The precise algorithms and
428	   heuristics, as well as, the complete set of management applications
429	   is beyond the scope of this document.

[nit] s/BGP-LS SPF/BGP SPF/g


[major] "whether or not BGP-LS SPF is used for route calculation, the
BGP-LS SPF route advertisements can be used"  The BGP SPF spec doesn't
cover a mode where routes are advertised, but route calculation is not
done.  Maybe you mean that the routes are not used (as in having a
less-preferred admin distance), or maybe you meant that BGP-LS (not
BGP SPF) is used -- but the text also says that "the base BGP-LS
routes [RFC7752] are not available" (base routes?).


431	6.5.4.  Data Center Interconnect (DCI) Applicability

433	   Since BGP SPF is to be used for the routing underlay and DCI gateway
434	   boxes typically have direct or very simple connectivity, BGP external
435	   sessions would typically not include the BGP SPF SAFI.

[minor] "would typically not include"  That is not a strong don't use.
What are the considerations for using BGP SPF, or not?


437	7.  Non-CLOS/FAT Tree Topology Applicability

439	   The BGP SPF extensions [I-D.ietf-lsvr-bgp-spf] can be used in other
440	   topologies and avail the inherent convergence improvements.
441	   Additionally, sparse peering techniques may be utilized Section 6.2.
442	   However, determining whether or to establish a BGP session is more
443	   complex and the heuristic described in Section 6.2.2 cannot be used.
444	   In such topologies, other techniques such as those described in
445	   [I-D.ietf-lsr-dynamic-flooding] may be employed.  One potential
446	   deployment would be the underlay for a Service Provider (SP) backbone
447	   where usage of a single protocol, i.e., BGP, is desired.

[major] This document is about applicability of BGP SPF in a DC, so
this section seems out of place.  Even if it was to remain, the text
doesn't provide any useful information (beyond the fact that BGP SPF
could be used elsewhere).


449	8.  Non-Transit Node Capability

451	   In certain scenarios, a BGP node wishes to participate in the BGP SPF
452	   topology but never be used for transit traffic.  These in include
453	   situations where a server wants to make application services
454	   available to clients homed at subnets throughout the BGP SPF domain
455	   but does not ever want to be used as a router (i.e., carry transit
456	   traffic).  Another specific instance is where a controller is
457	   resident on a server and direct connectivity to the controller is
458	   required throughout the entire domain.  This can readily be
459	   accomplished using the BGP-LS Node NLRI Attribute SPF Status TLV as
460	   described in [I-D.ietf-lsvr-bgp-spf].

[nit] "a BGP node wishes"  The operator wishes sometimes, I doubt the node does.


[nit] s/in include/include


[minor] For the case where a "server...but does not ever want to be
used as a router", please be a little more descriptive on the setup.
It seems that you're assuming that the server itself is running BGP
SPF (vs being connected through a router), right?  Of course, a server
might only be used as transit if multiple interfaces are used with BGP
SPF...  Please be explicit.


[minor] Same comment for the "controller is resident on a server" case.


462	9.  BGP Policy Applicability

464	   Existing BGP policy including aggregation and prefix filtering may be
465	   used in conjunction with the BGP-LS SPF SAFI.  When aggregation
466	   policy is used, BGP-LS SPF prefix NLRI will be originated for the
467	   aggregate prefix and BGP-LS SPF prefix NLRI for components will be
468	   filtered.  Additionally, link and node NLRI may be filtered and the
469	   abstracted by the prefix NLRI.

[major] Again, I didn't see a specification for aggregation in the BGP
SPF draft.


[minor] Is "abstracted by the prefix NLRI" the same thing as aggregation?


471	   When BGP policy is used with the BGP-LS SPF SAFI, BGP speakers in the
472	   BGP-LS SPF routing domain will not all have the same set of NLRI and
473	   will compute a different BGP local routing table.  Consequently, care
474	   must be taken to assure routing is consistent and blackholes or
475	   routing loops do not ensue.  However, this is no different than if
476	   tradition BGP routing using the IPv4 and IPv6 address families were
477	   used.

[major] Yes, it is different!  A link-state protocol is definitely
different than a path vector one.  Among other things, SPF depends on
everyone having a view of the topology.  Please include
considerations/consequences when applying filters.


...
483	11.  Security Considerations

485	   This document introduces no new security considerations above and
486	   beyond those already specified in the [RFC4271] and
487	   [I-D.ietf-lsvr-bgp-spf].

[major] True.  For the benefit of other readers, please include a
quick description of what this document is about:

For example>
   This document discusses the use of BGP SPF in a DC.  As a description of its
   use, it introduces no new...


...
513	13.2.  Informative References

515	   [CLOS]     "A Study of Non-Blocking Switching Networks",  The Bell
516	              System Technical Journal, Vol. 32(2), DOI
517	              10.1002/j.1538-7305.1953.tb01433.x, March 1953.

...
548	   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
549	              DOI 10.17487/RFC2328, April 1998,
550	              <https://www.rfc-editor.org/info/rfc2328>.

552	   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
553	              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
554	              DOI 10.17487/RFC4271, January 2006,
555	              <https://www.rfc-editor.org/info/rfc4271>.

[major] Because of §3, these 3 references must be Normative.  Please
see my comments there.


...
593	   [RFC7938]  Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
594	              BGP for Routing in Large-Scale Data Centers", RFC 7938,
595	              DOI 10.17487/RFC7938, August 2016,
596	              <https://www.rfc-editor.org/info/rfc7938>.

[major] The current text relies heavily on rfc7938.  As is, that would
require this reference to be Normative.  See my comments at the start
of this message.

[End of Review]