timevens / draft-ietf-grow-bmp-loc-rib Goto Github PK

The peer down doesn't include informational TLV's, which means the new TLV for table name cannot be used for hashing/identification of the peer by the receiver. This is fine because we use the RD for that purpose. It might be worth adding some text around how the table/vrf name is only informational and will not be part of the peer down.

Reference is: https://tools.ietf.org/html/rfc7854#section-8.2

• That the BMP local rib draft will be updated with a more verbose statement about the local-rib being only best path/selected NLRI's. While other RIB's exist, the BMP local-rib draft is only referring to the BGP selected routes/NLRI's RIB (all address families).

• Will add text for sender implementations to default local-rib to only send the address families configured for BMP monitoring. It is also acceptable that sender implementations may restrict combinations of Adj-RIB-In/Adj-RIB-Out pre/post policy and local-rib monitoring (e.g. a neighbor can be monitored for pre or post but not both at the same time, or that only a maximum of 4 address families can be enabled for local-rib monitoring). This should address the firehose situation with monitoring every address family by default.

• The draft calls out a filter flag to support filtered (reduced) local-rib's (e.g. send me only ebgp best path IPv4 prefixes)… This text will be expanded with more examples and will move to an INFO TLV from a per peer header flag. A per peer header flag doesn't make sense considering the filter doesn't apply to the message, it applies to the RIB at the session level (PEER_UP).

• Add-paths is a special case, which I'll add more details in the draft about not requiring that for local-rib. In the event the sender can use add paths to convey multipaths, the draft will go into more detail for the PEER UP capabilities advertisement and expected behavior.

• I'll also update the grow mailer that we feel adding a flag and info tlv to indicate FIB failures (e.g. rib/install failure due to another routing protocol having better priority/distance) will blur the line with BMP and FIB monitoring. FIB monitoring is valuable, but BMP is not where we should be doing that since that would require updating BGP itself.

SHOULD be added, but not required. Interval is in milliseconds.

• That the BMP local rib draft will be updated with a more verbose statement about the local-rib being only best path/selected NLRI's. While other RIB's exist, the BMP local-rib draft is only referring to the BGP selected routes/NLRI's RIB (all address families).

• Will add text for sender implementations to default local-rib to only send the address families configured for BMP monitoring. It is also acceptable that sender implementations may restrict combinations of Adj-RIB-In/Adj-RIB-Out pre/post policy and local-rib monitoring (e.g. a neighbor can be monitored for pre or post but not both at the same time, or that only a maximum of 4 address families can be enabled for local-rib monitoring). This should address the firehose situation with monitoring every address family by default.

• The draft calls out a filter flag to support filtered (reduced) local-rib's (e.g. send me only ebgp best path IPv4 prefixes)… This text will be expanded with more examples and will move to an INFO TLV from a per peer header flag. A per peer header flag doesn't make sense considering the filter doesn't apply to the message, it applies to the RIB at the session level (PEER_UP).

• Add-paths is a special case, which I'll add more details in the draft about not requiring that for local-rib. In the event the sender can use add paths to convey multipaths, the draft will go into more detail for the PEER UP capabilities advertisement and expected behavior.

• I'll also update the grow mailer that we feel adding a flag and info tlv to indicate FIB failures (e.g. rib/install failure due to another routing protocol having better priority/distance) will blur the line with BMP and FIB monitoring. FIB monitoring is valuable, but BMP is not where we should be doing that since that would require updating BGP itself.

Local RIb pre-policy and post policy to address table-map/filter as well as candidate protocols that have the same prefix but don't make it to local-rib due to admin/distance or similar.

This is a draft update, likely not implemented due to limitations/restrictions on maintaining or having a pre-policy (e.g. candidate) local-rib.