Subject: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Oct 2018 15:51:27 -0400

On Mon, Sep 17, 2018 at 01:00:22PM -0700, [email-masked] wrote:
>         Title           : Support for Local RIB in BGP Monitoring Protocol (BMP)

This question is motivated by an implementation in-progress:

In section 5, we have the following text:

:   Loc-RIB contains all routes from BGP peers as well as any and all
:   routes redistributed or otherwise locally originated.  In this
:   context, only the BGP instance Loc-RIB is included.  Routes from
:   other routing protocols that have not been redistributed, originated
:   by or into BGP, or received via Adj-RIB-In are not considered.

The second sentence is slightly confusing to me, and perhaps the usual
headache about the definition of loc-rib in RFC 4271, redistribution
(section 9.4 of same) and how other implementations work.

Somewhat colloquially, BGP implementations tend to concern themselves with
distribution of the "active" routes in most cases.  Thus, the routes that
get sent are the ones that are in the Routing Table in the RFC 4271 sense.
While there are scenarios where routes that are not the active route are
sent (e.g. add-paths, best-external, etc.), typically the active route is
sent.  This does interact with policy.

Policy normally will say "redistribute other protocol" in the circumstance
where for a given destination the best route is not BGP, but a BGP route is
present.

So... what exactly is intended by that second sentence?  It seems to read
"only pay attention to BGP routes".  

Based on the primary use case for loc-rib (avoid the need for a parallel BGP
session to your BMP rib-in session), I suspect what's intended is "send the
route that's eligible to be sent to BGP".

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 4 Oct 2018 21:06:31 +0100

> route that's eligible to be sent to BGP".

probably yes, although this may give an obscure view about what's 
actually happening on devices where the bgp route is inactive due to 
having been learned from a different routing protocol.  Is this 
something that can be flagged?

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 11 Oct 2018 12:19:23 -0400

> something that can be flagged?

"inactive due to having been learned from a different routing protocol".  

Nick, would you clarify with an example?

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 11 Oct 2018 17:35:30 +0100

> Nick, would you clarify with an example?

route X is learned via e.g. ISIS with precedence A.

route Y is learned via BGP with precedence B.

FIB is programmed with route X because precedence A trumps precedence B. 
  Route Y is marked as inactive (i.e rib-failure on ios).

I.e. normal operation of route selection, but BMP records BGP, so 
there's inconsistency as far as BMP is concerned, just how that relates 
to where packets are directed on the box.

Nick

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 11 Oct 2018 21:18:17 +0000

On 10/11/18, 9:35 AM, "GROW on behalf of Nick Hilliard" <[email-masked] on behalf of [email-masked]> wrote:

    

The local RIB in BMP should only contain what is/would be used/installed.  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.  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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 11 Oct 2018 17:22:34 -0400

[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?

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

[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. 
>

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 11 Oct 2018 21:33:16 +0000

On 10/11/18, 2:23 PM, "Jeffrey Haas" <[email-masked]> wrote:

    

It's the BGP best/selected route. 

    

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.   

    -- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 11 Oct 2018 21:56:23 +0000

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)" <[email-masked] on behalf of [email-masked]> wrote:

        

        

        
        -- Jeff
        
        > Unless others have hardship about adding this, I can do an update. 

    _______________________________________________
    GROW mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/grow

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 11 Oct 2018 23:20:25 +0000

Strongly support this good idea! I think this new INFO TLV will be very useful.

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Tim Evens (tievens)
Sent: Friday, October 12, 2018 5:56 AM
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

Thanks,
Tim 

    

    

        

        
        -- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 12 Oct 2018 00:16:39 +0000

Inline with [Shunwan]

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, October 12, 2018 5:23 AM
To: Tim Evens (tievens) <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

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

[Shunwan] IMO, the LocRib should include selected and used routes. We can consider some concrete examples.
Example 1:
If a router enable six parallel load balancing, and now there are 8 available candidate routes for one destination D.
In this case, there will be 6 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route.

Example 2:
If we enable BGP Fast Reroute (FRR) in a router, then there may exist a best route and a backup/alternate route in BGP for one destination D.
In this case, there will be 2 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route.

Is my understanding right?

Thanks again,
Shunwan

-- Jeff

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Oct 2018 10:01:09 -0400

Tim,

> It's the BGP best/selected route. 

Ok, that at least gives us something concrete to discuss.

> RIB failures due to another routing protocol preference is limited in
> scope to specific AFI/SAFI's (e.g. mainly IPv4/IPv6 unicast/multicast).

I don't recognize the term "RIB failure".

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

If you're saying "when the active route in the Routing Table (used for
forwarding) is not the best BGP route, and we're sending the best BGP route
in BMP as the loc-rib entry, we should flag that", then I at least
understand what you're saying.

So, I think we're back to my original points with better context:
The biggest motivation to have a "loc-rib" feed in BMP is to avoid the need
for a parallel BGP feed from a given router for correlation purposes.

BGP will advertise its active route in the majority of cases.

In the case where we're not putting the route that we're advertising into
this feed, we're basically bypassing the use case.

While I agree that the best bgp route is a useful thing, it's a somewhat
different use case.

---

I'll answer the followup mail once "rib failure" is explained.  I suspect
we're hitting implementation details, which are obscuring the discussion
from a vendor-neutral standards point.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Oct 2018 10:05:30 -0400

Shunwan,

> In this case, there will be 6 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route.

Loc-Rib in the RFC 4271 sense only covers selecting the best route, singular.

The fact that your FIB implementation may balance over that for ECMP
purposes is an implementation detail.

> In this case, there will be 2 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route.

Again, Loc-Rib in the RFC 4271 sense would consider only the best route.
The implementation is using the contents of the Adj-Rib-In to select
additional information for local forwarding purposes.  I.e. similar to the
ECMP case above.

-- Jeff

---

From: Qing Yang <[email-masked]>
Date: Fri, 12 Oct 2018 11:26:33 -0700

Right. And the locRib peer header doesn't really have way to do more than 1
anyway.

Some of our customers are also interested in knowing the 'best ecmp group'
instead of just locRib. For that, I think we really need to go with the
proposal that was thrown here about half year ago. Which is to allocate
another TLV to denote various flag bits, 'best ecmp' would be just one of
them. This allows the BMP feed to also serve 'multi purpose', in a way. So
one can actually correlate a post policy adjRibIn with the best ecmp, for
instance.

I wonder if there is a general interest in pursuing this further?

On Fri, Oct 12, 2018 at 7:06 AM Jeffrey Haas <[email-masked]> wrote:

> > > 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.
> >
> > If a router enable six parallel load balancing, and now there are 8
> available candidate routes for one destination D.
> > In this case, there will be 6 routes of the same destination D exist in
> the Loc-RIB, but only one of them is the best route.
>
> > If we enable BGP Fast Reroute (FRR) in a router, then there may exist a
> best route and a backup/alternate route in BGP for one destination D.
> > In this case, there will be 2 routes of the same destination D exist in
> the Loc-RIB, but only one of them is the best route.
>

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 13 Oct 2018 11:58:24 +0000

Jeff,

Thank you very much for your clear clarification of the BGP Loc-Rib!
I will look into RFC4271 again to understand this point. 

Thanks,
Shunwan

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, October 12, 2018 10:06 PM
To: Zhuangshunwan <[email-masked]>
Cc: Tim Evens (tievens) <[email-masked]>; [email-masked]
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

Shunwan,

The fact that your FIB implementation may balance over that for ECMP purposes is an implementation detail.

Again, Loc-Rib in the RFC 4271 sense would consider only the best route.
The implementation is using the contents of the Adj-Rib-In to select additional information for local forwarding purposes.  I.e. similar to the ECMP case above.

-- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 13 Oct 2018 12:27:41 +0000

Qing,

Inline with [Shunwan].

Thanks,
Shunwan

From: Qing Yang [mailto:[email-masked]]
Sent: Saturday, October 13, 2018 2:27 AM
To: Jeffrey Haas <[email-masked]>
Cc: Zhuangshunwan <[email-masked]>; [email-masked]
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

Right. And the locRib peer header doesn't really have way to do more than 1 anyway.
[Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a method to send best ecmp group to BMP Station.
BMP client can signal add-paths capability to BMP Station via BMP Peer UP message, then BMP Station will know that the client will send multiple NLRI for one destination.
That is my understanding.

Some of our customers are also interested in knowing the 'best ecmp group' instead of just locRib. For that, I think we really need to go with the proposal that was thrown here about half year ago. Which is to allocate another TLV to denote various flag bits, 'best ecmp' would be just one of them. This allows the BMP feed to also serve 'multi purpose', in a way. So one can actually correlate a post policy adjRibIn with the best ecmp, for instance.

On Fri, Oct 12, 2018 at 7:06 AM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Shunwan,

On Fri, Oct 12, 2018 at 12:16:39AM +0000, Zhuangshunwan wrote:
> > From: GROW [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeffrey Haas

-- Jeff

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Mon, 22 Oct 2018 14:45:50 +0000

On 10/13/18, 5:28 AM, "GROW on behalf of Zhuangshunwan" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Qing,

Inline with [Shunwan].

Thanks,
Shunwan

Correct.  The draft is not inventing another method to convey additional/best-routes.  BGP add-paths can be used to advertise the ECMP paths.  Note, this does not include ECMP where FIB is performing ECMP based on a single best-route next-hop/label/etc.   While add-paths supports sending non-best, IMO I would like the draft to restrict the usage of add-paths to only convey best-routes if using add-paths with local-rib.   IMO, FIB is out of scope for BMP.

--Tim