Skip to main content

6. Manageability Considerations

6. Manageability Considerations​

This section is structured as recommended in [RFC5706].

Existing BGP operational procedures apply. No new operation

procedures are defined in this document. It is noted that the NLRI

information present in this document carries purely application-level

data that has no immediate corresponding forwarding state impact. As

such, any churn in reachability information has a different impact

than regular BGP updates, which need to change the forwarding state

for an entire router. Furthermore, it is anticipated that

distribution of this NLRI will be handled by dedicated route

reflectors providing a level of isolation and fault containment

between different NLRI types.

Configuration parameters defined in Section 6.2.3 SHOULD be

initialized to the following default values:

  • The Link-State NLRI capability is turned off for all neighbors.

  • The maximum rate at which Link-State NLRIs will be advertised/ withdrawn from neighbors is set to 200 updates per second.

The proposed extension is only activated between BGP peers after

capability negotiation. Moreover, the extensions can be turned on/

off on an individual peer basis (see Section 6.2.3), so the extension

can be gradually rolled out in the network.

The protocol extension defined in this document does not put new

requirements on other protocols or functional components.

Frequency of Link-State NLRI updates could interfere with regular BGP

prefix distribution. A network operator MAY use a dedicated Route-

Reflector infrastructure to distribute Link-State NLRIs.

Distribution of Link-State NLRIs SHOULD be limited to a single admin

domain, which can consist of multiple areas within an AS or multiple

ASes.

Existing BGP procedures apply. In addition, an implementation SHOULD

allow an operator to:

  • List neighbors with whom the speaker is exchanging Link-State NLRIs.

The IDR working group has documented and continues to document parts

of the Management Information Base and YANG models for managing and

monitoring BGP speakers and the sessions between them. It is

currently believed that the BGP session running BGP-LS is not

substantially different from any other BGP session and can be managed

using the same data models.

If an implementation of BGP-LS detects a malformed attribute, then it

MUST use the 'Attribute Discard' action as per [RFC7606], Section 2.

An implementation of BGP-LS MUST perform the following syntactic

checks for determining if a message is malformed.

  • Does the sum of all TLVs found in the BGP-LS attribute correspond to the BGP-LS path attribute length?

  • Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute correspond to the BGP MP_REACH_NLRI length?

  • Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI attribute correspond to the BGP MP_UNREACH_NLRI length?

  • Does the sum of all TLVs found in a Node, Link or Prefix Descriptor NLRI attribute correspond to the Total NLRI Length field of the Node, Link, or Prefix Descriptors?

  • Does any fixed-length TLV correspond to the TLV Length field in this document?

An implementation SHOULD allow the operator to specify neighbors to

which Link-State NLRIs will be advertised and from which Link-State

NLRIs will be accepted.

An implementation SHOULD allow the operator to specify the maximum

rate at which Link-State NLRIs will be advertised/withdrawn from

neighbors.

An implementation SHOULD allow the operator to specify the maximum

number of Link-State NLRIs stored in a router's Routing Information

Base (RIB).

An implementation SHOULD allow the operator to create abstracted

topologies that are advertised to neighbors and create different

abstractions for different neighbors.

An implementation SHOULD allow the operator to configure a 64-bit

Instance-ID.

An implementation SHOULD allow the operator to configure a pair of

ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in

which the node participates.

Not Applicable.

An implementation SHOULD provide the following statistics:

  • Total number of Link-State NLRI updates sent/received

  • Number of Link-State NLRI updates sent/received, per neighbor

  • Number of errored received Link-State NLRI updates, per neighbor

  • Total number of locally originated Link-State NLRIs

These statistics should be recorded as absolute counts since system

or session start time. An implementation MAY also enhance this

information by recording peak per-second counts in each case.

An operator SHOULD define an import policy to limit inbound updates

as follows:

  • Drop all updates from consumer peers.

An implementation MUST have the means to limit inbound updates.

Last updated on