Subject: [GROW] BMP loc-rib Peer-Type behavior

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Dec 2018 16:04:39 -0500

Authors,

In section 4.1, we define a new peer type to cover the loc-rib.  This is
mostly a pointer to section 4.2 of RFC 7854.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Peer Type   |  Peer Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Peer Distinguisher (present based on peer type)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address (16 bytes)                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Peer AS                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Peer BGP ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Timestamp (seconds)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp (microseconds)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My question is with regards to Peer AS and Peer BGP ID:

If either of those fields are altered on the router, what is the expected
behavior in BMP?

I have opinions, but would like to see yours. :-)

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Dec 2018 02:29:13 +0000

Sending a peer-down followed by a peer-up seems reasonable to me.
Changing these requires a new OPEN message to neighbors, so everything
is going to bounce anyway.

Yours?

Regards,
Jakob.

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Tuesday, December 11, 2018 1:05 PM
To: [email-masked]; [email-masked]
Subject: [GROW] BMP loc-rib Peer-Type behavior

Authors,

      0                   1                   2                   3

-- Jeff

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Dec 2018 06:50:30 -0500

> is going to bounce anyway.

I think so as well.

But what of the route monitoring messages?

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Dec 2018 18:14:17 +0000

I would leave those alone. Sending them again adds no new information.
The BMP server can switch the ASN and BGP-ID on its own if it wants.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Thursday, December 13, 2018 3:51 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

I think so as well.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Dec 2018 13:49:54 -0500

Jakob,

> The BMP server can switch the ASN and BGP-ID on its own if it wants.

That's my impression too.  However, if the implementation treats the
peer-down as an implicit flush it won't work cleanly.

This means that something in the header needs to indicate "I'm
updating some state, hold on to your RMs".

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Thu, 13 Dec 2018 19:58:19 +0100

Hi Jakob, Jeff,

+1 for the peer down / peer up sequence for the scenario described (and in general for changes to the peer, like peer address?).

But not re-sending RMs after the peer up seems very unclean to me. True we can invent an extra mechanism to say hold on your routes, like Jeff says, but i see the extra complexity with that (do we really need it?): it would work if the BMP server is building RIBs out of received RMs but what about more streaming data scenarios? Not to speak that if there was a route flap in BGP, due to the OPEN, you are effectively hiding it. Not BGP Monitoring Protocol anymore.

Paolo  

> On 13 Dec 2018, at 19:49, Jeffrey Haas <[email-masked]> wrote:
> 
> Jakob,
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Dec 2018 19:12:08 +0000

Wait, a BMP server is not a BGP peer. It does not replicate a routing table.
It is a logger/processor of information. It doesn't "delete" older information,
just because some newer information arrived.
Its purpose it to tell you what happened at some time in the past,
because you are trying to debug a problem or do some capacity planning
or whatever. Just because a BGP router changed its BGP-ID does not mean
that all the routes it had 2 days ago magically did not happen.

Regards,
Jakob.

-----Original Message-----
From: Paolo Lucente <[email-masked]> 
Sent: Thursday, December 13, 2018 10:58 AM
To: Jeffrey Haas <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

Hi Jakob, Jeff,

Paolo

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Dec 2018 14:26:09 -0500

Jakob,

> that all the routes it had 2 days ago magically did not happen.

RFC 7854:
:    A Peer Down message implicitly withdraws all routes that were
:    associated with the peer in question.  A BMP implementation MAY omit
:    sending explicit withdraws for such routes.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Dec 2018 20:26:49 +0000

Most of the routes will be deleted anyway.
Only the locally originated routes will remain.

I would suggest to keep the implicit withdraw behavior and not
to explicitly withdraw any loc-rib routes when they go away.
That means, the BGP speaker will send BMP loc-rib peer-down,
not withdraw any routes to BMP and resend the locally originated
routes again.

I don't believe GR activates in this case, because when the ASN or
BGP-ID changes, a NOTIFICATION will be sent. Can someone confirm?

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Thursday, December 13, 2018 11:26 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Paolo Lucente <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

Jakob,

RFC 7854:

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Dec 2018 17:40:33 -0500

Jakob,

> not withdraw any routes to BMP and resend the locally originated

That was my reading as well.  But I had the similar observation that it's an
awful lot of useless work if you don't need it.  But to have that take
effect, it'd require behavioral changes in the peer down message.

This was a corner case.  I think it's worth documenting it in the draft, but
it seems we have at least two parties that agree on the expected semantics.

Thanks!

-- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Fri, 14 Dec 2018 00:47:06 +0000

NOTE: Sorry for the delay... end of year commitments are pressing... Addressing these comments in descending order. 

See inline marked [tievens]

On 12/13/18, 12:26 PM, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

[tievens] As in the previous response, we have no choice but to clear the list/RIB and start over upon PEER DOWN/UP in order to maintain a consist Loc-RIB (e.g we are not just a log of history events, we are maintaining the RIB that should mirror the router's RIB state).  Local-RIB peer should not result in a DOWN just because one or more peers have gone down.  The expected behavior is that Loc-RIB peer will send withdraws or updates based on changes, as it would for Adj-RIB-Out.     

[tievens] A change in BGP-ID is a change in BMP peer header. This MUST require a peer DOWN and PEER UP.
    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Jeffrey Haas <[email-masked]> 
    Sent: Thursday, December 13, 2018 11:26 AM
    To: Jakob Heitz (jheitz) <[email-masked]>
    Cc: Paolo Lucente <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [GROW] BMP loc-rib Peer-Type behavior
    
    Jakob,

    RFC 7854:
    
    -- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Fri, 14 Dec 2018 00:55:36 +0000

On 12/13/18, 11:27 AM, "Jeffrey Haas" <[email-masked]> wrote:

    Jakob,

    RFC 7854:
    
    -- Jeff

[tievens] This is the expected behavior... we mark all RIB entries as withdrawn/stale upon peer DOWN/UP. Note, there is no guarantee that we will receive a peer down (e.g. router term or connection failure), so upon PEER up we mark previous entries as withdrawn.  We expect that a PEER up will be followed by a RIB DUMP with the current state of the RIB. We expect updates following the RIB DUMP that will reconcile and maintain the state.   RFC7854 doesn't address the transient changes happening during the RIB dump.   For example, it takes 1 minute to complete the RIB dump but about the changes during that dump?  IMO, they should be buffered and replayed.  This is a topic that is not specific to this draft but does need to be addressed.

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Fri, 14 Dec 2018 01:08:38 +0000

On 12/13/18, 10:58 AM, "Paolo Lucente" <[email-masked]> wrote:

    Hi Jakob, Jeff,

    
[tievens] This is classic state exchange and the reason why a RIB dump is needed upon PEER UP. It is simple to exchange the current state.  IMO, it will be more complex to implement a reconciling method to sync the BMP server (receiver) based on delta changes from time T1 to Tn.  A reconciling method will require the router to track where the BMP server is in terms of the RIB state and to exchange updates relative to new connect time.  BGP doesn't even attempt to do this, for good reason!  I believe the confusion with Jakob's response is that he is thinking we (the receivers) are log endpoints, which is totally not true.  Logging BGP changes are only part of the monitoring.   We fully expect to use BMP to monitor the RIB states, just like we have been doing with MRT(TABLE_DUMP/BGP4MP_MESSAGE) and PCAP for the past several years. 

    Paolo

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Fri, 14 Dec 2018 01:19:30 +0000

On 12/11/18, 1:05 PM, "GROW on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Authors,

          0                   1                   2                   3

    

[tievens] Per this draft, the BGP-ID and ASN are set to the global/default value or based on VRF (Local-RIB it conveys).   The simple answer is if you change distinguishing (peer identity) values in the per-peer-header, you will need to send a PEER DOWN (using old values) and PEER UP (using new values). Regardless of this draft, if you send a new per-peer header with different values (sans type, flags, and timestamps), the receiver is likely going to treat that as a different peer. We/OpenBMP, and I believe others, use peer rd, peer addr, peer asn, and peer id as distinguishing identify for a peer, which enables us to multiplex different peers over the same TCP (bmp) stream. 

    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Dec 2018 08:05:26 -0500

Tim,

> NOTE: Sorry for the delay... end of year commitments are pressing... Addressing these comments in descending order. 

I know this feeling well. :-)

> [tievens] Per this draft, the BGP-ID and ASN are set to the global/default
> value or based on VRF (Local-RIB it conveys).   The simple answer is if
> you change distinguishing (peer identity) values in the per-peer-header,
> you will need to send a PEER DOWN (using old values) and PEER UP (using
> new values). Regardless of this draft, if you send a new per-peer header
> with different values (sans type, flags, and timestamps), the receiver is
> likely going to treat that as a different peer. We/OpenBMP, and I believe
> others, use peer rd, peer addr, peer asn, and peer id as distinguishing
> identify for a peer, which enables us to multiplex different peers over
> the same TCP (bmp) stream. 

Excellent, I believe we concur on this detail.

I'd like to suggest that some text be added to the loc-rib draft covering
this detail.  Thanks!

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Mon, 17 Dec 2018 08:15:44 -0500

> On Dec 13, 2018, at 2:12 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 

Actually there are consumers who treat it like this.  This is why on up we 
get a dump of what the router might have in adj-rib-in, then get deltas.

It is the expectation of a consumer they will get this data similar to being a BGP peer.

- Jared