Skip to main content

Early Review of draft-ietf-lsvr-bgp-spf-02
review-ietf-lsvr-bgp-spf-02-rtgdir-early-frost-2018-08-21-00

Request Review of draft-ietf-lsvr-bgp-spf-01
Requested revision 01 (document currently at 31)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-08-24
Requested 2018-08-01
Requested by Gunter Van de Velde
Authors Keyur Patel , Acee Lindem , Shawn Zandi , Wim Henderickx
I-D last updated 2018-08-21
Completed reviews Opsdir Early review of -01 by Fred Baker (diff)
Rtgdir Early review of -02 by Dan Frost (diff)
Rtgdir Last Call review of -13 by Yingzhen Qu (diff)
Rtgdir Last Call review of -31 by Adrian Farrel
Comments
The LSVR standardisation work can be enhanced with help of an early review from both the Routing Directorate and Operational Directorate.
Assignment Reviewer Dan Frost
State Completed
Request Early review on draft-ietf-lsvr-bgp-spf by Routing Area Directorate Assigned
Reviewed revision 02 (document currently at 31)
Result Has issues
Completed 2018-08-21
review-ietf-lsvr-bgp-spf-02-rtgdir-early-frost-2018-08-21-00
Hello,

I have been selected to do a routing directorate "early" review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf

The routing directorate will, on request from the working group chair, perform
an "early" review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft's lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document has recently been adopted by the working group, my focus for
the review is on providing a new perspective on the work, with the intention of
catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-lsvr-bgp-spf-02
Reviewer: Dan Frost
Review Date: 2018-08-21
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Comments:

This document proposes extensions to BGP that in effect allow it to operate as
a shortest-path-first link-state routing protocol. The cited motivation is the
wide deployment of BGP in large data-center networks, combined with the
deficiencies of BGP when deployed in said networks. Admirably, the authors
avoid any hint of irony when describing this state of affairs.

Taking its premise as given, the draft is clear and well-written, addressing
important details but remaining concise throughout. The Introduction (Section
1) is particularly good, providing the necessary context and relevant
references.

A few further comments:

- This comment is primarily intended for the ADs and not specific to this
draft. For quite a long time now, the IETF has been in the mode of extending
BGP to carry ever more diverse forms of data, some of which are, at best,
tenuously connected to routing. BGP is being used as an ad hoc distributed
general-purpose database because of its flexibility, deployment scale, and
implementation maturity. In many ways this is a testament to the robustness of
BGP's design and the ingenuity of engineers faced with an ever-growing list of
requirements to share more and more data. The fact remains, though, that BGP
was not designed to be a general-purpose distributed database. With every new
BGP extension RFC that adds a few more AFI/SAFIs and TLVs and a new set of
processing rules, this becomes more painfully obvious. At some point
(preferably 20 years ago) we need to look beyond the tactical level and produce
or adopt a solution designed to address the root problem and fit to last for
the next 50 years. There's a strategic hole of monumental proportions here.

- Section 2 on Peering Models is a little too brief. The draft would benefit
from expanded discussion of the possibilities here and some detailed examples.
Alternatively, this could be the focus of a separate document.

- The usage of the sequence number discussed in Sections 4.4 and 5.1 is not
entirely clear to me from the text, particularly the implications of a sequence
number reset. Some examples as to how convergence works in this case would help.

- The third paragraph of Section 5 states, regarding rapid propagation of
changed NLRI: "To accomplish this, the MinRouteAdvertisementIntervalTimer and
MinRouteAdvertisementIntervalTimer [RFC4271] are not applicable to the
BGP-LS-SPF SAFI." For one thing the same timer is listed twice here. More
generally, since BGP SPF routing is apparently not going to be governed by the
usual BGP timers, a more complete specification is needed here. Any deviations
should be itemized and thoroughly documented. Do new timers and knobs specific
to BGP SPF need to be introduced? How is the operator expected to control these
parameters?

- A Manageability Considerations section for the benefit of operators seems
particularly important given the deviations of BGP SPF from classic BGP
operation. This should summarize, at least, things like timer differences,
applicability or non-applicability of specific policy mechanisms, impact of
restarts and sequence number resets, and any new configuration parameters that
implementations should provide and operators should be aware of.

Cheers,
-d