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

[Alvaro Retana <[e-mail]>]

On February 15, 2021 at 10:55:53 AM, Acee Lindem wrote:

Hi!

This message covers the remaining set of up-front comments/questions.

Thanks!

Alvaro.


...
> > (2) Use of the BGP-LS encodings.
> >
> > - This document is effectively defining a new AFI/SAFI combination -- yes,
> > related to BGP-LS, but not the same. IOW, you can define which parts of
> > rfc7752 apply (if any), beyond the encodings.
>
> We have added section 3 to address the relationship to BGP-LS.


307	3.  BGP Link-State (BGP-LS) Relationship

309	   [RFC7752] describes a mechanism by which link-state and TE
310	   information can be collected from networks and shared with external
311	   entities using BGP.  This is achieved by defining NLRI advertised
312	   using the BGP-LS AFI.  The BGP-LS extensions defined in [RFC7752]
313	   make use of the decision process defined in [RFC4271].  This document
314	   reuses NLRI and TLVs defined in [RFC7752].  Rather than reusing the
315	   BGP-LS SAFI, the BGP-LS-SPF SAFI Section 5.1 is introduced to insure
316	   backward compatibility for the BGP-LS SAFI usage.

[nit] s/NLRI/the NLRI/g

[nit] s/SAFI Section 5.1/SAFI (Section 5.1)


318	   The BGP SPF extensions reuse the Node, Link, and Prefix NLRI defined
319	   in [RFC7752].  The usage of the BGP-LS NLRI, attributes, and
320	   attribute extensions is described in Section 5.2.  The usage of
321	   others BGP-LS attributes is not precluded and is, in fact, expected.
322	   However, the details are beyond the scope of this document and will
323	   be specified in future documents.

[nit] s/will be specified/may be specified

[] "others BGP-LS attributes"

There is only one BGP-LS Attribute.  This got me thinking about
clarifying, simplifying and avoiding some redundancy.

Suggestion>

   [Eliminate this sentence from the previous paragraph: "This document
   reuses NLRI and TLVs defined in [RFC7752]."]

   The BGP SPF extensions reuse the format of the Link-State NLRI, the
   BGP-LS Attribute, and the TLVs defined in [RFC7752bis]. The usage of
   is described in Section 5.2. The usage of others BGP-LS TLVs or
   extensions is not precluded and is, in fact, expected. However, the
   details are beyond the scope of this document and may be specified
   in future documents.

   [Eliminate the next paragraph.]


325	   Support for Multiple Topology Routing (MTR) similar to the OSPF MTR
326	   computation described in [RFC4915] is beyond the scope of this
327	   document.  Consequently, the usage of the Multi-Topology TLV as
328	   described in section 3.2.1.5 of [RFC7752] is not specified.

[] See the suggestion above.


[major] Also, unless used as part of the specification, please avoid
references to other protocols -- specially comparing them.



330	   The rules for setting the NLRI next-hop path attribute for the BGP-
331	   LS-SPF SAFI will follow the BGP-LS SAFI as specified in section 3.4
332	   of [RFC7752].

[major] Now that we have rfc7752bis -- it is not just about the NH
attribute, but the contents of the MP_REACH_NLRI attribute as well.

Suggestion>
   The BGP-LS-SPF SAFI uses the specification in Section 5.5 of
   [RFC7752bis] related to the BGP Next-Hop Information.



...
> > - Which Protocol-ID should be used for the NLRI? ??4 suggests 7 (BGP), but
> > I think that is not correct (see more there). What should the receiver do
> > with a different value?
>
> We have clarified this in section 5.2.

>From §5.2:

490	   The protocol identifier specified in the Protocol-ID field [RFC7752]
491	   will represent the origin of the advertised NLRI.  For Node NLRI and
492	   Link NLRI, this MUST be the direct protocol (4).  Node or Link NLRI
493	   with a Protocol-ID other than direct will be considered malformed.
494	   For Prefix NLRI, the specified Protocol-ID MUST be the origin of the
495	   prefix.

[major] "For Prefix NLRI, the specified Protocol-ID MUST be the origin
of the prefix."

What value is that?  Do you expect anything other than Direct?


[minor] The text in rfc7752bis talks about "sourcing" not "origin".

Suggestion>
   The Protocol-ID "Direct" MUST be used in all NLRI.  Any other
   Protocol-ID value results in the NLRI considered malformed.


[] BTW, rfc7752bis opens the door to use other Protocol-IDs even for
local information:  "The 'Direct' and 'Static configuration' protocol
types SHOULD be used when BGP-LS is sourcing local information."
Given that BGP SPF is using the formats from BGP-LS, but not following
all the rules, it could use it's own Protocol-ID.

Regardless of the above, it would be a good idea for this document to
request a new Protocol-ID so that BGP-LS can use it to collect/export
link-state information from BGP SPF.  I haven't thought much about
this: would anything else be needed to enable BGP-LS to carry BGP SPF
or could it just export as-is?



...
> > (3) Link-State
> >
> > - How does BGP SPF guarantee that the nodes are synchronized? Other
> > protocols have DBDs/CSNP/etc. It seems easier in BGP SPF to not exchange
> > all the information with a peer than it is in traditional link-state
> > protocols. Being able to easily break synchronization is a vulnerability
> > that should be mentioned in the Security Considerations section.
>
> Hmmm... Of your high-level meta-comments, this one is a good point.

Thanks! ;-)


> We will discuss how to document this difference and whether an optional
> extension is needed.

So?  I didn't see anything about synchronization in the current version.