Henk,
On 3/26/18, 6:13 AM, "GROW on behalf of Henk Smit" <[email protected] on
behalf of [email protected]> wrote:
What the new drafts propose:
----
The new drafts introduce new ways to report routes from the Adj-RIB-Out
and Loc-RIB to bmp-stations.
The Adj-RIB-Out draft does that by using a flag from the BMP per-peer
header's flag-field. This new flag indicates that a reported route is
from the Adj-RIB-Out in stead of the Adj-RIB-In.
I don't like this.
<tievens> Utilizing a flag for this follows RFC7854 in that the peer being
monitored can convey either Adj-RIB-In or Adj-RIB-Out for Pre-Policy and
Post-Policy, hence flags L and O.
===
The flags-field has only 8 bits. We were using 3 of them. This draft
uses a 4th. And the Loc-RIB draft introduces yet another flag. We'll
be running out of flags soon.
<tievens> I believe you missed that loc-rib draft updates RFC7854 by
making flags specific to the peer type. We updated 7854 to change flags
to be specific by peer type while also not breaking the current
7854 draft/bmp version support of the existing peer types. Hence,
the existing peer flags are unchanged and therefore do not require
a version change in BMP. Flags by peer type is introduced in
local-rib draft, which specifically introduces a new peer type to
support this without breaking anything else.
Below is from draft-ietf-grow-bmp-local-rib-01 where it indicates
flags are specific to the peer type. In other words, 8 bits available
per peer type. I can see how the below can be overlooked, so we can update
the draft sections 4.1 and 4.2 to clearly indicate that flags are now
specific by peer type.
8.2. BMP Peer Flags
This document defines a new flag (Section 4.2) and proposes that peer
flags are specific to the peer type:
o The F flag indicates that the Loc-RIB is filtered. This indicates
that the Loc-RIB does not represent the complete routing table.
===
The Loc-RIB draft introduces a new peer-type, the so-called
"Loc-RIB Instance Peer". Note, we already had a "Local Instance Peer".
I don't find this naming very clear. I also don't like mixing three
different types of routes (In, Out, Loc) in the same message-type.
<tievens> Revision 01 changed this statement to specifically call out why a
new peer type was introduced. If this isn't clear, we can further clarify it
more, including adding that that flags are specific to the peer
type, not global.
"A new peer type is defined for Loc-RIB to distinguish that it
represents Loc-RIB with or without RD and local instances.
Section 4.2 [RFC7854] defines a Local Instance Peer type, which is
for the case of non-RD peers that have an instance identifier."
I agree that local-instance needs to be better clarified in RFC7854.
We discussed with John why RFC7854 introduced local-instance peer and how it
is a bit misleading. He mentioned it was added to support local instance/RD
peers (e.g. local vrf) where there isn't a route-distinguisher. Instead
a locally unique RD would be used. In this local-instance case, it still can
represent
a peer.
BMP adoption by vendors and open-source (FRR, Bird, ...) has been moving at
glacial
rates, including Nokia's lack of support. 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 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. We
have
been advocating with both vendors and customers to adopt BMP as the prefer
method
for BGP monitoring. Customers are now finally requesting it, which is likely
why
you now have priority to implement it.
Changing the version, when it doesn't really need to changed, adds unnecessary
backwards compatibility complexity with existing and new implementations. 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.
Change of RFC7854 local-instance usage borders on, if not mandates, a version
changed. Instead, I’m for a bis update, which we have been talking about with
John, to clarify the use of local-instance peer, that or deprecate it.
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.
===
The other comments are related to RFC7854 and suggest significant changes
requiring a re-write of BMP. Your comments have merit and we have
been talking about this regarding a BIS update instead of a version change.
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.
--Tim
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
