draft-ietf-grow-bmp-loc-rib's People
draft-ietf-grow-bmp-loc-rib's Issues
Include post/pre policy for local-rib
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.
Add reference.
Add something about why we don't use peer type 2/local-instance peer
Add new Info TLV for state compression interval
SHOULD be added, but not required. Interval is in milliseconds.
Updates to make
-
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.
change to "error prone task"
"it is possible" is back to back... change
Updates based on vendor discussion
-
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.
Peer down doesn't include info, might want to add additional details for receiver
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.