Hello Tim,
My apologies for the delayed response.
While you might say you don't like the drafts, including 7854, and
that maybe it's the reason why vendors haven't implemented it...
I do like RFC7854. And I do like the ideas behind the two new drafts.
I only have a problem with the syntax. It's not extensible.
I think we should alter the format of route-monitoring messages in BMP.
I'd like to see a syntax that would allow us in the future to add any
information to BMP that becomes required.
And I think we can do it with minimal changes to the current protocol.
And with minimal changes to implementations.
I would disagree. We have been working with both vendors and customers
for the past 3 years to implement BMP. The reason why BMP is not
implemented is NOT because the drafts don't work or cannot be
implemented
as defined, it's because vendors (including BIRD and FRR) didn't have
the customer demand to prioritize it.
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.
Changing the version, when it doesn't really need to changed, adds
unnecessary backwards compatibility complexity with existing and new
implementations.
Then we shouldn't bump the version.
I think it's a small effort to add a knob in routers to advertise the
current BMP format, or use a new format with three new TLV-based
route-monitoring messages. After all, all other messages stay the same.
And the route-monitoring messages would just get a different
message-type
and a TLV-header inserted. That is all.
This effects both sender and receiver implementations. While I can
update SNAS/OpenBMP to handle the complexity with this, other large
cloud/service providers have already implemented their own non-public
BMP receivers that would also have to be updated.
Agreed.
But again, it wouldn't be such a big change. And routers can easily be
programmed to send either the new or the old syntax. It's a relatively
small change.
It should be NOTED that there are many items we have talked about
updating
in the RFC7854bis. I would prefer a separate thread to talk about the
bis related items.
I have not seen that discussion, sorry. Are those discussions archived
in the grow-mailing-list archive ?
I hope I can participate in future discussions.
I would like John and Jeff's comments on this, but if a version change
is the direction we would like to go, then I would like to discuss all
the
changes we have been talking about for the bis updates, not just the
few you mentioned below.
My point was not to bump BMP version's number.
Let me re-iterate my points.
But this time in the reverse order of reasoning.
1) Route-monitoring messages are not extensible.
If we want to make BMP truly extensible, we should make
route-monitoring
messages also TLV-based.
Look at BGP (attributes) and IS-IS (TLVs and sub-TLVs).
Those protocols have been unchanged since the early nineties.
Only new attributes, TLVs and sub-TLVs have been added.
I'd like BMP to have a similar long life-time.
2) I don't like it if things like peer-flags in the peer-header have
different meaning based on context. Or message-content not
depending on msg-type, but on peer-type. It'll make things less
clear.
It'll prevent us from doing sensible things in the future.
I am also afraid that we'll run out of bits in the peer-flags field.
3) Therefor I'd like to split the peer-flags.
Some flags are indeed about the peer (e.g. ipv4 vs ipv6
peer-address).
Others are not about the peer, but about the route (pre/post policy,
4b-asn).
Let's use the peer-flags only for information about the peer.
And when we introduce TLVs for route-monitoring messages, let's make
a TLV for flags in route-mon messages regarding the routes
themselves.
The benefit here is that such a TLV can hold a huge amount of flags.
(256 bytes * 8 bits = potentially 2048 flags in one TLV).
4) We have to make sure receivers know what to expect. The major thing
is
whether route-monitoring messages use TLVs or not. And it has to be
done in a backward compatible way. We can do that by introducing 1
new
msg-type, or 3 new msg-types (Adj-Rib-in, Adj-Rib-out and Loc-Rib),
or
by bumping the BMP version number.
I have no real preference here. I think splitting route-mon msgs into
three would be the cleanest solution. In that case, we don't need to
bump the version number.
Summary:
1) split route-monitoring message into 3 msgs: Rib-Adj-in, Rib-Adj-out,
Loc-rib.
2) make route-mon message TLV-based
3) the only 2 TLVs we need now are: a) BGP update message itself. b)
flags.
That's all. I don't think this would require much effort to change
router or
collector implementations.
henk.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
