Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

There were a number of scenarios where the control plane could be compromised. It is important to be aware that the intention here was for services that were configuration i.e VPLS/BGP ( Kompella ), FlowSpec and “staler” services i.e L3VPN where an operator would prefer a degree of incorrectness as opposed to a total outage..

I am speaking from a perspective of AT&T’s network.

a)      RR Plane Failure – AT&T runs a large L3VPN network, the amount of state easily reaches into the tens of millions. To accommodate this state I employed an architecture/design that disseminates the state across multiple planes of RRs with a given VPN’s routes spread across the planes. Assuming each plane accommodates ~1M routes the risk to a significant outage where an entire plane is compromised would be the percentage of that VPNs routes on that given plane. The planes are made of gear from multiple vendors but we have seen an ill formed message from a  bad actor take out an entire plane.

b)      Isolation – Geography in different parts of the world may cause a part of the network to be disconnected from the control plane. I have seen this in Africa, Asia and the states. As an ex… If my RR pair is in Atlanta and provides control plane for Florida a loss of the Atl RRs will cause an intra-FLA failure.. So a BGP/VPWS circuit between Miami and Tampa would be compromised by the loss of the Atl RRs. One may suggest that the answer is simple and one can simple increase the densification of RRs. Of course it would be RR pair * Planes for a given service. This is a poor tradeoff that will be incremental in nature

At the end of the day BGP is used for far more than originally envisioned with many “configuration” applications ( FlowSpec, BGP/VPLS ), reporting applications ( BGP-LS …. ).. BGP Persistence provides a simple method to maintain forwarding and leaves it to the discretion of the operator in terms of stale time, services etc….

Thanks,
                Jim Uttaro

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, May 22, 2018 3:17 PM
To: Warren Kumari <warren@kumari.net>
Cc: idr wg <idr@ietf.org>; draft-ietf-idr-bgp-gr-notification@ietf.org; The IESG <iesg@ietf.org>; idr-chairs@ietf.org
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Hi Warren,

To understand this proposal a little lecture of document which was proposed before this one and which in fact triggered this extension can be helpful:

https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Duttaro-2Didr-2Dbgp-2Dpersistence-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=Mfi0hMnnFb0vEnycEIXjQgmkfYxT-y3LnpZJ3cFmKzk&e=>

Effectively here authors propose to allow BGP speaker to run in a headless mode indefinitely. The root of the idea was born when pure control plane single vendor RRs go down for hours and otherwise healthy PEs running in healthy network stop serving 1000s of VPN customers.

I think at this stage I will refrain from stating an opinion on it. All I can say is that operators today can use so many other dangerous knobs in various address families of BGP that adding this configuration flexibility to GR stale timer option here will rather not make it much worse :)

Kind regards,
Robert.

On Tue, May 22, 2018 at 8:53 PM, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>> wrote:
Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-gr-notification-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=3Tbh94yAZspqlfRQHR4YPGTsgU-hJEpeMUuPOkEaZPQ&e=>
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dgr-2Dnotification_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=kYoC7D2UM0o-LWBCEFUaHYVXhS82I2AZeROv52MtJec&e=>

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm sure that this has already been discussed somewhere, and that I'll be able
to quickly clear my DISCUSS once pointed at it, but: "To put an upper bound on
the amount of time a router retains the stale routes, an implementation MUST
support a (configurable) timer, called the "stale timer", that imposes this
upper bound. A suggested default value for the stale timer is 180 seconds. An
implementation MAY provide the option to disable the timer (i.e., to provide an
infinite retention time) but MUST NOT do so by default."

The "infinite retention time" part of this makes me deeply uncomfortable -- I
can see a good reason for the stale timer, and the default "feels" fine to me,
but having an infinite retention time (or, really anything over 10 to 15
minutes) feels like a really dangerous idea, and that it will come back and
bite.

I'm hoping that I'm missing something obvious, but can you please explain under
what conditions an infinite retention policy makes sense? It seems like there
would be multiple opportunities for blackholing traffic with this.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=ieg4cO4Kawle23szINir4SwrtTBmGKMSsylYY6gy9qk&e=>