Re: [GROW] BMP loc-rib Peer-Type behavior
NOTE: Sorry for the delay... end of year commitments are pressing... Addressing these comments in descending order. See inline marked [tievens] On 12/11/18, 1:05 PM, "GROW on behalf of Jeffrey Haas" wrote: 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. :-) [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 ___ 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
Re: [GROW] BMP loc-rib Peer-Type behavior
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, 10:58 AM, "Paolo Lucente" wrote: 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. [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 > On 13 Dec 2018, at 19:49, Jeffrey Haas wrote: > > Jakob, > > On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote: >> From: Jeffrey Haas >>> On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: 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. >>> >>> I think so as well. >>> >>> But what of the route monitoring messages? >> >> 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. > > 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 > > ___ > 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
Re: [GROW] BMP loc-rib Peer-Type behavior
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, 11:27 AM, "Jeffrey Haas" wrote: Jakob, On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote: > 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. 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 [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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
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)" wrote: 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. [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. 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? [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 Sent: Thursday, December 13, 2018 11:26 AM To: Jakob Heitz (jheitz) Cc: Paolo Lucente ; draft-ietf-grow-bmp-local-...@ietf.org; grow@ietf.org Subject: Re: [GROW] BMP loc-rib Peer-Type behavior Jakob, On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote: > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
Jakob, On Thu, Dec 13, 2018 at 08:26:49PM +, Jakob Heitz (jheitz) wrote: > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
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 Sent: Thursday, December 13, 2018 11:26 AM To: Jakob Heitz (jheitz) Cc: Paolo Lucente ; draft-ietf-grow-bmp-local-...@ietf.org; grow@ietf.org Subject: Re: [GROW] BMP loc-rib Peer-Type behavior Jakob, On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote: > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
Jakob, On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote: > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
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 Sent: Thursday, December 13, 2018 10:58 AM To: Jeffrey Haas ; Jakob Heitz (jheitz) Cc: draft-ietf-grow-bmp-local-...@ietf.org; grow@ietf.org Subject: Re: [GROW] BMP loc-rib Peer-Type behavior 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 wrote: > > Jakob, > > On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote: >> From: Jeffrey Haas >>> On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: 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. >>> >>> I think so as well. >>> >>> But what of the route monitoring messages? >> >> 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. > > 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 > > ___ > 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
Re: [GROW] BMP loc-rib Peer-Type behavior
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 wrote: > > Jakob, > > On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote: >> From: Jeffrey Haas >>> On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: 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. >>> >>> I think so as well. >>> >>> But what of the route monitoring messages? >> >> 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. > > 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 > > ___ > 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
Re: [GROW] BMP loc-rib Peer-Type behavior
Jakob, On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote: > From: Jeffrey Haas > > On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: > > > 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. > > > > I think so as well. > > > > But what of the route monitoring messages? > > 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. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
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 Sent: Thursday, December 13, 2018 3:51 AM To: Jakob Heitz (jheitz) Cc: grow@ietf.org; draft-ietf-grow-bmp-local-...@ietf.org Subject: Re: [GROW] BMP loc-rib Peer-Type behavior On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: > 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. I think so as well. But what of the route monitoring messages? -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BMP loc-rib Peer-Type behavior
On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote: > 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. I think so as well. But what of the route monitoring messages? -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
