Re: [Lsvr] AD Review of draft-ietf-lsvr-bgp-spf-11

[Alvaro Retana <[e-mail]>]

On November 27, 2020 at 10:14:34 AM, Alvaro Retana wrote:

Hi!


...
> I haven't read draft-ietf-lsvr-applicability yet -- if some of the answers
> are there, please point me to it. When I finish that document I'll consider
> whether the documents need to be returned to the WG. For now, I'll rely on
> the Shepherd to help in moving this document forward.

I just finished my review of the applicability draft (sent
separately), and have decided to return both documents to the WG.

While considering the other document, a couple of additional
comments/questions came up.  Please see below -- I tried to put them
where they might have made sense within the original review, but are
new points.

Thanks!

Alvaro.



...
> - In a "traditional" link-state protocol, there are a number of LSAs that
> define a node: router LSA, network LSA, etc. Please describe how a node is
> fully described in BGP SPF -- and how the different NLRIs are associated to
> describe that one node. ...

[major] lsvr-applicability talks about the ability of controllers (or
other boxes) to listen in on BGP SPF (I'm calling it a "listening
node").  Is there an expectation that a BGP SPF peer should advertise
a description of itself?

If so, then a "listening node" needs to be specified so that it
doesn't end up attracting traffic.

If not, then not advertising a local description is equivalent to not
being available for transit -- if done on purpose (by a rogue node,
for example) may result in a partitioned topology, DoS, etc..


...
> 157 A primary advantage is that all BGP speakers in the BGP SPF routing
> 158 domain will have a complete view of the topology. ...

[major] §6.5.5/lsvr-applicability talks about using BGP SPF to provide
Topology Visibility.  How can BGP SPF be used that way?  Assuming that
flooding happens before SPF runs (or even regardless of whether it
does), I guess that it would be possible to use BGP SPF (and not
BGP-LS) to discover the topology.  This case may be possible whether
of not BGP SPF is used for routing (or has a less-preferred admin
distance).  Is that something you want to add to the specification?
Would a don't-run-SPF mode make sense?

Assuming that topology discovery/visibility is a specified application
of BGP SPF, we should contrast it with BGP-LS.  Several things come to
mind: the general distribution model is different, the consumer in
BGP-LS is a "listening node" in BGP SPF, the source of the information
is different (which may or may not be congruent with the IGP)...


...
> 253 2.3. BGP Peering in Route-Reflector or Controller Topology
...
> 263 This peering model, known as sparse peering, allows for many fewer
> 264 BGP sessions and, consequently, instances of the same NLRI received
> 265 from multiple peers. It is discussed in greater detail in
> 266 [I-D.ietf-lsvr-applicability].

[] RR/Controllers not congruent with the data path.  This is a typical
BGP configuration, but in the case of BGP SPF, we end up with typical
controller/SDN type issues where the communication goes to the
controller before even the directly connected peer (except for link
liveliness).  Also, what if the connection to the controller is
affected by the connectivity of the network itself?

I made a similar comment in the lsvr-applicability draft, but because
route-reflection (at least the function) is mentioned several times in
this document, then it would be idea to include considerations about
the (general) use.


[major] The applicability draft focuses on the use of BGP SPF in a DC.
What about other uses?  In general, it seems to me that BGP SPF could
be used in many of the same environments where a link-state protocol
is used; with the caveats of having a single flooding domain, no
dynamic peer discovery,...  It might be a good idea to add something
like that (a paragraph or two) somewhere, and point to the
applicability draft for specifics about DC (and not just a specific
peering model, as above).


...
> [major] Can the BGP SPF session also support other AFI/SAFI pairs? If so,
> what are the implications/limitations because of the peering models. Should
> this document (similar to rfc7752bis) recommend/require the isolation of BGP
> SPF in it's own BGP session? Why/why not? IMHO, it should be required.

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.
Is that something that a BGP SPF implementation in a DC should
consider?


...
> [major] What about the AS_PATH?

lsvr-applicability (§6.3) talks about using a filter based on the
AS_PATH.  What checking should be done on the AS_PATH?  Should the
receiver check for an AS loop (which is specified in Phase 2 of the
Decision Process)?