My original response might have not been that clear with regards to adding a
new INFO TLV to indicate support of sending inactive NLRI's that are in
conflict with another routing protocol. Some implementations do not have an
option to be so flexible, so they may only support one or the other. By
indicating the intent to the BMP receiver, we enable the receiver to handle the
updates correctly. IMO, it would be ideal if the BMP sender can advertise and
indicate in a peer header flag that **all** NLRI's in the RM BGP UPDATE are in
conflict due to another routing protocol with a better preference.
What I suggest is a new INFO TLV in the PEER UP to indicate:
(a) the BMP local rib will include rib-failure NRLI's with a peer flag
indicating not-used due to another routing protocol/direct/static,
(b) will not send rib-failure NLRI's,
(c) will send rib-failure NLRI's but will not support the peer flag
If the PEER UP doesn't include this INFO_TLV, it'll be treated as (c).
Thanks,
Tim
On 10/11/18, 2:33 PM, "GROW on behalf of Tim Evens (tievens)"
<grow-boun...@ietf.org on behalf of tiev...@cisco.com> wrote:
On 10/11/18, 2:23 PM, "Jeffrey Haas" <jh...@pfrc.org> wrote:
[Trimming original thread to re-ask my core question.]
On Thu, Oct 11, 2018 at 09:18:17PM +0000, Tim Evens (tievens) wrote:
> The local RIB in BMP should only contain what is/would be
used/installed.
From where? BGP's best route? The routing table's active route?
It's the BGP best/selected route.
> In other words, the local rib sent via BMP should not contain the
> suppressed prefixes that were not installed due to another routing
> protocol/direct/static having a better preference.
Which ties into the RFC question about where other protocols are
injected
into the Decision Process.
If you read the RFC as literally saying it's injecting it into the
Decision
Process (section 9.4), the LocRib should be the best route and thus the
active route regardless of whether it was learned from BGP or not.
RIB failures due to another routing protocol preference is limited in scope
to specific AFI/SAFI's (e.g. mainly IPv4/IPv6 unicast/multicast). For this
use-case of installation/rib-failures where the prefix would be used but cannot
be installed seems to justify a flag/info_tlv to indicate that.
[rest left in for future context]
-- Jeff
> I think we should
> allow the implementation to suppress the inactive or to advertise the
> inactive prefixes. We can use a per-peer flag to indicate that the
> NLRI's in the RM/BGP UPDATE are suppressed due to another routing
> protocol/direct/static having better preference. We'll also need to
add a
> new INFO TLV in the PEER UP to indicate the expected conveyance of
> inactive/rib-failure NLRI's.
>
> Unless others have hardship about adding this, I can do an update.
>
>
> Thanks,
> Tim
>
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
