Indeed.
What I propose(d) is basically three things:
1) Create 3 new route-mon message-types to replace the existing
route-mon msg. One each for:
a) Adj-Rib-In, b) Adj-Rib-Out, and c) Loc-Rib
2) Make these new messages TLV-based.
3) Define 2 TLVs:
a) a TLV that is basically just a BGP update message.
b) a TLV for all the flags that apply to a route.
this partially replaces the flags-field in the per-peer header.
Having a larger flags-field will allow us to report any state of
the route to the bmp-collector. Some state that might be useful is:
1) route is pre-policy
2) route is post-policy
3) route is accepted by policy
4) route is rejected by policy
5) route is best BGP route after bgp-best-path-computation
6) route is not best BGP route after best-path computation
7) route is installed in RTM (global routing table)
8) route is not installed in RTM
9) route is used/best route in RTM
10) route is not used/best route in RTM
11) as-path is in 4-byte ASN notation
12) NLRI(s) have path-id (add-paths)
13) NLRI(s) do not have path-id
14) route was not re-advertised, but only policy changed
15) route is valid
16) route in invalid (e.g. because next-hop is not valid).
(I propose to use 2 bits for some state. That way a router can
let the bmp-collector know that it doesn't know the state (yet)).
I'm sure operators can come up with a lot more state that they would
like to report to their bmp-collectors.
And any state that does not fit in a 1-bit flag-field, can be reported
using a new TVL. E.g. reason why a route was rejected (policy name and
line-number), reason why a route was installed or not, etc. That's
the benefit of moving to TLV-based encoding.
I agree with what Randy suggests, that the basic change (without
adding new functionality) does not have to be a lot of work. At least
not in my implementation.
henk.
Randy Bush schreef op 2018-06-25 15:52:
I'm not saying the drafts don't work. I'm trying to look ahead. And
I am convinced that route-monitoring messages should be TLV
based. And if we agree that we have to make that change some day, I
think we should change it asap.
I see your point and there are good ideas you raise and i think it
will definitely be good conversation to have. My take is that what
you
propose is forward looking and broader scope than what the two
currently active drafts actually touch. I would hence propose to not
conflate things: the two drafts add much needed functionality to the
BMP protocol to extend its coverage in terms of use-cases; conflating
will effectively stall the current process and relegate operators
needing visibility in the 5 vantage points identified (Adj-RIB-In
pre-
and post-policies, loc-rib and Adj-RIB-Out pre- and post-policies) to
methods as bad as screen scraping for yet more years to come.
if my reading is correct, ...
i do not think that is what henk is saying at all. he is not
suggesting
racical semantic change. he is suggesting more easily understood and
processed syntax. this is the kind of change you can make in O(week).
btw, do not read my comment as supporting (or not) henk's proposal. i
just wanted to clarify it. my usual response to this kind of proposal
is "send code."
randy
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
