Re: [Lsvr] Alvaro's Remaining Comments: New Version Notification for draft-ietf-lsvr-bgp-spf-27.txt

[Alvaro Retana <[e-mail]>]

[+ lsvr]

Acee:

Hi!

I looked at the diffs.

The main changes are in the additional text in §7.1 to cover the Descriptor
TLVs, and the new §7.4.


In §7.1, the new text is incomplete; many of the new sentences don't point
at the source of the IGP information, just at rfc7752bis, where no semantic
validation rules are specified.  For example:

   Node Descriptor TLVs and their error handling rules are either defined
in
   section 5.2.1 of [I-D.ietf-idr-rfc7752bis].

The text also doesn't specify what BGP SPF-specific action should be taken
if there’s an error (like it does for some of the other TLVs).

Finally, some of the TLVs come from non-IGP sources.  The BGP Identifier
TLV is an example of that -- it comes from rfc9086, which is not even used
as a reference.



The new section says this:

   7.4. BGP-LS-SPF Link State NLRI Database Synchronization

      While uncommon, there may be situations where the LSNDBs of two BGP-
      LS-SPF speakers lose synchronization. In these situations, the BGP
      session MUST be reset. The mechanisms to detect loss of
      synchronization are beyond the scope of this document.

Resetting the session should result in a resync, so it is not a bad
recommendation.  [A route refresh could also be used.]

All the cases of BGP-LS drop and treat-as-withdraw specified in §7.1 lead
to loss in synchronization and resetting the session won't necessarily fix
the problem.  In the specific case of §5.1.2 (where the BGP-LS attribute is
discarded because of the message size) the action will result in the
session bouncing forever -- and all the other routes being lost,
potentially leaving a part of the network without any reachability.

A rogue node can then remove the BGP-LS attribute, or manipulate the TLVs
to cause any other error to affect the whole session -- not just a single
route.  IOW, the impact is beyond that is mentioned in the Security
Considerations:

   If an authorized BGP peer is compromised, that BGP peer could advertise
   modified Node, Link, or Prefix NLRI which result in misrouting,
repeating
   origination of NLRI, and/or excessive SPF calculations.



As I said in my previous message [1], I will leave it to Jim to decide if
the document is ready for IETF LC.


Thanks!

Alvaro.



[1] https://mailarchive.ietf.org/arch/msg/lsvr/53qx9ERNrHek1U4OphEHQJrhT_o/

On July 26, 2023 at 1:49:46 PM, Acee Lindem ([e-mail]) wrote:

Hey Alvaro,

Please look at this version rather than the rfcdiff that I sent previously.
There were some typos in that diff.

Thanks,
Acee

> On Jul 26, 2023, at 10:45, [e-mail] wrote:
>
>
> A new version of I-D, draft-ietf-lsvr-bgp-spf-27.txt
> has been successfully submitted by Acee Lindem and posted to the
> IETF repository.
>
> Name: draft-ietf-lsvr-bgp-spf
> Revision: 27
> Title: BGP Link-State Shortest Path First (SPF) Routing
> Document date: 2023-07-26
> Group: lsvr
> Pages: 40
> URL: https://www.ietf.org/archive/id/draft-ietf-lsvr-bgp-spf-27.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/
> Html: https://www.ietf.org/archive/id/draft-ietf-lsvr-bgp-spf-27.html
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf
> Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsvr-bgp-spf-27
>
> Abstract:
> Many Massively Scaled Data Centers (MSDCs) have converged on
> simplified layer 3 routing. Furthermore, requirements for
> operational simplicity has led many of these MSDCs to converge on BGP
> as their single routing protocol for both their fabric routing and
> their Data Center Interconnect (DCI) routing. This document
> describes extensions to BGP to use BGP Link-State distribution and
> the Shortest Path First (SPF) algorithm. In doing this, it allows
> BGP to be efficiently used as both the underlay protocol and the
> overlay protocol in MSDCs.
>
>
>
>
> The IETF Secretariat
>
>