Subject: Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

From: Job Snijders <[email-masked]>
Date: Sat, 1 Dec 2018 18:05:24 +0100

Hi all,

Have the authors and Jeff Haas managed to discuss (and maybe resolve) what
was raised by Jeff?

Let’s extend WGLC with another week - I’m also not seeing a lot of feedback
on whether this document should progress. GROW please take a look and let
the group know how the continue.

Kind regards,

Job

On Tue, Nov 20, 2018 at 6:42 Tim Evens (tievens) <[email-masked]> wrote:

> Hi Jeff,
>
> Best route for sure, unless add-paths is used. I would like to understand
> your use-case more... When you mention the customer has to use "parallel
> BGP sessions for active route state," are you saying that the customer
> needs to establish multiple "monitoring" BGP peering sessions in order to
> obtain what would have been available via BMP Adj-RIB-In Post Policy
> monitoring?
>
>
> Thanks,
> Tim
>
> On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     I do wish to get this point resolved.  We have inconsistent pressure
> from our own customer base as to whether they want to monitor best bgp vs.
>     "please give me something to let me stop needing parallel BGP sessions
> for active route state".
>     [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.
>     Per my limited knowledge about BMP, I don't understand why we need
> "parallel BGP sessions for active route state", Sorry.  Can you explain it
> in detail?
>
>

---

From: Lizhenbin <[email-masked]>
Date: Thu, 6 Dec 2018 01:46:16 +0000

Yes/Support.

Best Regards,
Zhenbin(Robin)

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Friday, November 09, 2018 10:13 PM
To: [email-masked]
Subject: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

Dear GROW,

As suggested in the working group meeting in Bangkok, draft-ietf-grow-bmp-local-rib may ready for last call. The last call will be 2 weeks, ending November 26th, 2018.

Abstract:

    The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In
    and locally originated routes (e.g. routes distributed into BGP from
    protocols such as static) but not access to the BGP instance
    Loc-RIB. This document updates the BGP Monitoring Protocol (BMP)
    RFC 7854 by adding access to the BGP instance Local-RIB, as defined
    in RFC 4271 the routes that have been selected by the local BGP
    speaker's Decision Process. These are the routes over all peers,
    locally originated, and after best-path selection.

The document is at https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib

Please review the document and provide feedback.

The internet-draft authors should note that Jeff Haas contributed a comment to the IETF 103 GROW jabber room that unfortunatly wasn't read out loud. This comment should be considered input into the last call
process:

    jhaas> "For loc-rib draft, list discussion was over whether we should
    advertise active route vs. best bgp route. Best bgp route means
    that you still need an active bgp session to monitor actual bgp and
    doesn't simplify use case."
    https://www.ietf.org/jabber/logs/grow/2018-11-05.html

Kind regards,

Job & Chris

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Dec 2018 17:31:55 -0500

[Note, message reordered and reformatted for quoting clarity]

Tim,

Thank you for your patience for my response.

On Tue, Nov 20, 2018 at 05:42:37AM +0000, Tim Evens (tievens) wrote:
> On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" <[email-masked] on behalf of [email-masked]> wrote:
> > Jeff Haas said:
> > > I do wish to get this point resolved.  We have inconsistent pressure from our own customer base as to whether they want to monitor best bgp vs.
> > > "please give me something to let me stop needing parallel BGP sessions for active route state".  
> > 
> > [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.  
> >     Per my limited knowledge about BMP, I don't understand why we need "parallel BGP sessions for active route state", Sorry.  Can you explain it in detail?
>

Today, customers running stock BMP (RFC 7854) often tend to have a parallel
BGP peering session with their routers to monitoring stations.  This permits
them, in many cases, to correlate the results of BGP received paths vs. path
selection.

Sticking with a simplified example with BGP running its path selection
solely on BGP routes, the active route in the system's RIB may end up being
non-BGP.  Typical examples are static routes, or IGP routes winning out over
BGP routes.  I.e. "administrative distance".

The route used for forwarding will be the active route in the RIB.

BGP itself will advertise the active route in most implementations in most
circumstances.

The issue in a simplified example:
If the active route for a destination is a static route, a customer may want
to know this vs. the best BGP route.  This is needed to check why forwarding
is happening as expected.

Why not use rib-out?  Because other BGP features may cause a route that
isn't the active route to be sent.  E.g. best-external.

The problem is thus: Does the customer want to receive a loc-rib feed vs.
the route being actively used for forwarding, or do they want to see the
best BGP route?  We've had requests for both, depending on use case -
typically "BGP monitoring and path analysis" vs. "forwarding validation vs.
route selection".

A further complicating factor is that some implementations let non-BGP
routes be effectively injected into the BGP route selection process in ways
that make "best route using BGP route selection" somewhat more ambiguous.

---

Add-paths is also somewhat ambiguous, I think, in a loc-rib context as it is
specified in the current draft.

If we are to send only the contents of the rib, is the path-id intended to
reflect the learned path-id from a given peer's route?  If so, I'm a bit
confused by Shunwan's point about ecmp groups.  This is because in order to
safely send the ecmp contributors via add-paths encoding, we must overwrite
the received path-id and locally generate it.  Clearly we do this in a
rib-out context, but that's not what I thought we were discussing here.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Dec 2018 22:45:15 +0000

Hi Jeff, 

On 12/10/18, 5:33 PM, "GROW on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Tim,

    

    

    

Just because a piece of information is useful doesn't necessarily mean it should be part of the BGP local RIB. In many cases, the BGP process and the Global RIB are deaggregated. If we wish to overload BMP with returning the contents Global-RIB, then it should be a separate table. 

Thanks,
Acee

    ---

    
    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Dec 2018 20:44:16 -0500

Acee,

On Mon, Dec 10, 2018 at 10:45:15PM +0000, Acee Lindem (acee) wrote:
> Just because a piece of information is useful doesn't necessarily mean it
> should be part of the BGP local RIB. In many cases, the BGP process and
> the Global RIB are deaggregated. If we wish to overload BMP with returning
> the contents Global-RIB, then it should be a separate table. 

Be mindful that having worked on the RFC 4271 revision, I'm a bit particular
about BGP definitions and abstraction details.

One of the details that was always an awkward fit was where routes entered
the BGP abstract models.  I've already posted it, but let's post it again:

: 9.4.  Originating BGP routes
: 
:    A BGP speaker may originate BGP routes by injecting routing
:    information acquired by some other means (e.g., via an IGP) into BGP.
:    A BGP speaker that originates BGP routes assigns the degree of
:    preference (e.g., according to local configuration) to these routes
:    by passing them through the Decision Process (see Section 9.1).

By pedantic definition, this is how we get things into Loc-Rib.  I'm not the
one who chose the name of the draft we're discussing, but if we're going to
talk "loc-rib", let's at least be clear.   

Customers want one of two use cases and I have customers who want them
both:
1. The route in loc-rib as used for forwarding to avoid needing a parallel
BGP session.
2. The best bgp route.

The current draft, due to the way Loc-Rib is specified in 4271, isn't
crystal clear in terms of what we'll get in the above case.

In the loc-rib draft, section 1.1 talks about deriving the state by
monitoring an adjacent system's adj-rib-in.  This corresponds to 1 above,
except when BGP advertises something it doesn't use for forwarding.  See
prior commentson the rib-out spec.

Section 5 of the draft has the following:
: 5.  Loc-RIB Monitoring
: 
:    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.

There is no "BGP Instance Loc-Rib".  What I believe is intended by the
authors is "The Loc-Rib in an implementation wherein the BGP routing state
is segregated".  The "have not been redistributed" also implies a specific
implementation model that is also not necessarily congruent with 4271.

And that's *FINE*.  But the text needs to be cleaned up if so.  That would
push it up to #2 in my two cases.  But for the customers that need #1?
You've just told that part of the user-base "go run parallel BGP".  Or,
alternatively, "hey, Jeff, we're not covering your use case, copy 90% of the
loc-rib draft text and add more code points".

Or perhaps finally, "ah, we understand the distinction, how do we simply
ship a single loc-rib draft that covers both".  But that's only a
conversation to have after we've gotten over the definition phase.

-- Jeff

---

From: John Scudder <[email-masked]>
Date: Fri, 14 Dec 2018 23:40:57 +0000

Hi All,

I apologize for the late reply to the WGLC. I have a couple of comments I'd like to raise. I'll start by saying that although I'm going to bring up a couple problems with draft-ietf-grow-bmp-local-rib, I think at least the second was inherent in RFC 7854, and I will start a different mail thread to discuss the problem and proposed fix in more detail. (Not to keep anyone in suspense, I think it was a mistake to have the Initiation and Peer Up messages share a namespace. More broadly I think the authors, ahem, of 7854 didn't drink enough of the TLV koolade before finalizing it.)

Issue 1. draft-ietf-grow-bmp-local-rib says:

   Peer down notification SHOULD follow the section 4.9 [RFC7854] reason
   2.

   The VRF/Table Name informational TLV SHOULD be included if it was in
   the Peer UP.

This doesn't make sense to me, since the definition of reason 2 in RFC 7854 section 4.9 doesn't allow for any extra data:

   o  Reason 2: The local system closed the session.  No notification
      message was sent.  Following the reason code is a 2-byte field
      containing the code corresponding to the Finite State Machine
      (FSM) Event that caused the system to close the session (see
      Section 8.1 of [RFC4271]).  Two bytes both set to 0 are used to
      indicate that no relevant Event code is defined.

One fix, I think the more expedient one, would be to request a new reason code ("TBD3"), whose format includes both the content carried in reason 2, and a VRF/Table Name. Then if you want to send the table name, you use the new reason code.

An alternate fix, somewhat more involved but possibly useful in the long run, would be to update RFC 7854 to permit Peer Down messages to carry additional data beyond the reason code and its own associated data, and then to define the format of that data. Probably the additional data would be TLVized. It would obviously need to have a registry created for it.

By the way, shouldn't those "SHOULDs" be "MUSTs"? If not MUST, under what circumstances MAY they be omitted?

Issue 2. draft-ietf-grow-bmp-local-rib says:

   The following peer UP information TLV types are added:

   o  Type = TBD2: VRF/Table Name.  The Information field contains an
      ASCII string whose value MUST be equal to the value of the VRF or
      table name (e.g.  RD instance name) being conveyed.  The string
      size MUST be within the range of 1 to 255 bytes.

      The VRF/Table Name TLV is optionally included.  For consistency,
      it is RECOMMENDED that the VRF/Table Name always be included.  The
      default value of "global" SHOULD be used for the default Loc-RIB
      instance with a zero-filled distinguisher.  If the TLV is
      included, then it SHOULD also be included in the Peer Down
      notification.

Nit1, "types are added" should be "type is added".

Nit2, I'm not crazy about the definition of string here, and ASCII should almost certainly be UTF-8. I will offer a replacement definition in the other thread I'll start.

Nit3, all those SHOULDs. Can't they be MUSTs? If not, can you give the reader a hint of why not?

The real problem (this is the one that came from RFC 7854): though the text says "peer UP information TLV types are added", there is no such thing as the peer UP information TLV! We could fix this by adding the type to the Information TLV, which in RFC 7854 is shared by Initiation and Peer Up. However I think it is a cleaner fix to separate the namespaces, one for Initiation and one for Peer Up. Once that's done (and it should be easy unless there's controversy), just allocate the TLV out of the (to be created) Peer Up Message TLVs registry. (This is what I'm starting a new thread to discuss.)

Thanks,

--John

---

From: John Scudder <[email-masked]>
Date: Mon, 17 Dec 2018 21:37:51 +0000

One further thought to this:

> On Dec 14, 2018, at 6:40 PM, John Scudder <[email-masked]> wrote:
> 
...
> This doesn't make sense to me, since the definition of reason 2 in RFC 7854 section 4.9 doesn't allow for any extra data:
...
> An alternate fix, somewhat more involved but possibly useful in the long run, would be to update RFC 7854 to permit Peer Down messages to carry additional data beyond the reason code and its own as…

It occurs to me that the main reason I can think of NOT to adopt this option would be that existing BMP server implementations might choke on new-style PDUs as described above, since they are illegal per the base spec. The fact RFC 7854 is underspecified as to what if any error checking and enforcement should be done, makes this maybe somewhat less of a concern (there's no mandated "you must reset the session upon protocol errors") but there's still no guarantee a server wouldn't experience an internal error.

Whether the WG thinks this is a genuine concern or not, is a matter for discussion. Reasons to think it's not a big deal include,

- I would hope most server implementations would be robust to this kind of malformation, but I don't actually know, I can just apply the "well that's how I would have done it" heuristic, which a pretty weak one.
- Presumably the extra (nonconformant to RFC 7854) TLV would only be emitted when Loc-RIB functionality was configured, and presumably Loc-RIB functionality would only be configured if the server on the other end supported consuming it (otherwise why bother), Q.E.D. only a compliant server would see the new TLV.

Reasons to think it is a big deal include reflexive conservatism, which is not always a bad thing in networking standards. 

By contrast, the other option I offered, allocating a new Reason code that includes a string field, is guaranteed to be backward-compatible with compliant implementations. And by "guaranteed" I mean "probably" since I see RFC 7854 section 4.9 doesn't explicitly say "you have to be tolerant of unrecognized Reason codes", however, I think this is a pretty good bet. It's certainly the more conservative option.

$0.02,

--John

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 19 Dec 2018 01:42:26 +0000

Hi Jeff, 

I'm also sorry for the delay.  There have been some year end commitments that have taken my available cycles. 

See inline marked [tievens]

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

    Tim,

    

[tievens] That sounds like what we have been doing as well... basically trying to use Adj-RIB-Out to monitor local-Rib, which hasn't worked too well, especially with originated in bgp data. 

[tievens] IMO, the "active route in the system's RIB" is more of the FIB table, where it takes into account conflicting sources of data (ISIS, OSPF, BGP, static/direct, and any variance of multi-instances).  This convergence of route sources with preference/selection, IMO, is out of scope for BGP monitoring.  BGP monitoring by itself is very important to monitor.  The monitoring station (bmp receiver) can apply admin preference between the available sources of data (bgp-ls with ISIS and OSPF) to identify which one is used over the other, but it'll never replace the "system rib/fib."  BGP Loc-RIB is just what BGP has across all afi/safi's.  IMO, we will always need to monitor BGP, ISIS, and OSPF, but we also do need FIB.  I see FIB monitoring including egress interface/port granularity (lag port, not just the lag interface), source identifier of protocol and protocol instance, etc.  Something will have to be done with FIB monitoring to also address the hashing/lb based on l4/input/etc.

[tievens] BGP Loc-RIB is what the router has in, or available to, BGP that would be sent to a peer. 

[tievens] Agreed. There will be cases where another protocol will be preferred over BGP's learnt entry. BGP will still advertise (to peer and Loc-RIB) prefix A via next-hop C but the router is actually forwarding prefix A via next-hop Z based on another protocol having better preference. 

[tievens] Agreed, but this is not "BGP loc-RIB" monitoring.  This would be FIB or System RIB monitoring which is different.  This in IMO requires egress interface level info, specifically to address the issue with lag ports/members.  This level of monitoring also does not need all the BGP attributes or be required to conform to BGP... What's available and needed depends on the route source.  For example, ISIS TLV's, static route locally significant attributes, etc.   The FIB/System RIB level monitoring can be simpler than BGP encoding with more flexible attribute conveyance... I hate to say it because I prefer BGP in most cases, but System/FIB monitoring with multiple route sources to consider is, IMHO, better served with flexible models/schemas.  

[tievens] I think the confusion is that loc-rib is NOT the router's FIB.  It is the BGP loc-RIB and will only convey what's in/available to BGP as it would send out (e.g. rib-out). Adj-RIB-Out and Loc-RIB are very similar, which is sometimes confused.  The key difference between Adj-RIB-Out and Loc-RIB (context is BGP) drafts are that Loc-RIB does not require you to have an actual peer with a remote system and it does not suffer from transport or afi/safi restrictions that would otherwise be imposed by a peering session (e.g. IPv4 vs IPv6).

    ---

    
    -- Jeff