Re: [v6ops] Stability and Resilience (was Re: A common...)

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 22 February 2019 17:05 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17759130FE2; Fri, 22 Feb 2019 09:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJODLQWa2O6z; Fri, 22 Feb 2019 09:05:16 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0B8130F8A; Fri, 22 Feb 2019 09:05:15 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9373C3826C; Fri, 22 Feb 2019 12:05:03 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id DA2B21DBD; Fri, 22 Feb 2019 12:05:13 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D7A3D1DB1; Fri, 22 Feb 2019 12:05:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Lee Howard <lee@asgard.org>
cc: ipv6@ietf.org, IPv6 Ops WG <v6ops@ietf.org>
In-Reply-To: <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <0629af5e-5e1b-7e01-5bf4-b288a2d36809@asgard.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 22 Feb 2019 12:05:13 -0500
Message-ID: <1620.1550855113@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tq457w5P1bkjYqNJqv39LeemCj0>
Subject: Re: [v6ops] Stability and Resilience (was Re: A common...)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 17:05:22 -0000

Lee Howard <lee@asgard.org> wrote:
    > 2

    > Aggregate above the provider edge device, so that grooming customers
    > between Provider Edge boxes (PEs) doesn't force a renumbering. It's been a
    > few years since I worked on CMTSs, but when I did they did not support
    > MP-BGP well (if at all), so routes had to be aggregated on the PE, or
    > leaked in the IGP which is bad for convergence time. Maybe PE vendors can
    > report.

I don't understand this comment/concern about convergence time.

I was the architect at a PE vendor (PPPoE, not CMTS, but from the north-interface, it is
pretty similar) for a numbers of years.  [2012 to 2017, parttime].

We didn't support BGP; we got no call for it as an IGP.
We supported OSPF/OSPFv3, and we assumed aggregation above the provider edge
devices. We counselled our customers to make an OSPF area for this, and
so it naturally aggregated above, and the customer grooming did not leak out
of the area.
Few of our customers' IPv6 usage grew very much during this time, so I can't
say if this turned out to be a problem.

The customers for whom this was a problem architecturally had the problem
that their network was so small that they the "above" point was their EBGP
device anyway.    We're talking about rather small ISPs with O(10^3)
customers here :-) (that would be the entire country/island)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-