Subject: Re: [GROW] The new BMP drafts and new BMP functionality

From: Paolo Lucente <[email-masked]>
Date: Mon, 25 Jun 2018 00:18:56 +0200

Hi Henk,

> On 30 Apr 2018, at 17:01, Henk Smit <[email-masked]> wrote:
> 
> I think we should alter the format of route-monitoring messages in BMP.
> 
>> [ .. ]
> 
> 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 there is sufficient agreement on the current drafts, they should be let progress and a separate conversation (to which i’d be more than happy to contribute effort to) should start; if there is not sufficient agreement, we should iron divergences out and focus on wrapping the current drafting effort up.

Paolo

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Jun 2018 21:39:41 -0700

>> 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 hank 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).

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Jun 2018 06:52:00 -0700

> i do not think that is what henk is saying at all.  he is not suggesting

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

---

From: Paolo Lucente <[email-masked]>
Date: Mon, 25 Jun 2018 16:54:33 +0200

> On 25 Jun 2018, at 15:52, Randy Bush <[email-masked]> wrote:
> 
> is "send code.”

Precisely, agree. It is what i meant with the second paragraph of my previous email, with the “if there is not sufficient agreement, we should iron divergences out and focus on wrapping the current drafting effort up.”. I would like to see some text with the proposal.

Paolo

---

From: Henk Smit <[email-masked]>
Date: Mon, 25 Jun 2018 18:07:52 +0200

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.