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

[Alvaro Retana <[e-mail]>]

Dan:

Hi!

Sorry for the long delay in replying.  This draft has now moved into my
queue and I am in process of reviewing — part of that is checking the
mailing list, so I hadn’t seen your comment before. :-(


Yes, I tend to personally agree with you with regards to the use/abuse that
BGP faces.

Because the IETF works “from the bottom up”, it is up to the participants
to define alternative mechanisms as a general transport, or to take other
measures to protect BGP.  In the specific case of BGP SPF, I am explicitly
raising the question to the authors/WG about isolation of the BGP SPF
sessions.  Similar steps are being taken for BGP-LS (in rfc7752bis).

BTW, I also agree with your other comments pointing at a more complete
specification.  My review should be done in a few days.

Thank you for the review!

Alvaro.

On August 21, 2018 at 10:31:36 AM, Dan Frost ([e-mail]) wrote:

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