Re: [RTG-DIR] RtgDir Early Review: draft-ietf-lsvr-bgp-spf-02

["Acee Lindem (acee)" <[e-mail]>]

Hi Dan, 

Please see updated -03 version. Also see inline responses preceded by "Acee:". 

On 8/21/18, 10:31 AM, "rtg-dir on behalf of Dan Frost" <[e-mail] on behalf of [e-mail]> wrote:

    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.

Acee: This would a good question for NOMCOM to pose to potential Routing Area ADs. __
    
    - 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.

Acee: I've explained the simpler peering models and deferred the last one to the LSVR Applicability draft. 
    
    - 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.

Acee: I've added text to section 5. 
    
    - 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?

Acee: I've corrected this. The parameter will be covered in the manageability section. 
    
    - 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.

Acee: I've added a Manageability Section. It doesn't include everything you've asked for, but, after all this is an early review.

Thanks,
Acee
    
    Cheers,
    -d