On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
> On 09/11/2022 15:48, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> >> as far as that /128 is not used as BGP next-hop (which obviously is not
> >> the case),
>
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> On 09/11/2022 15:26, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> >> and why that would be a problem? Such prefix would never be used to for
> >> r
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachab
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> I guess I'd like to understand what one would accomplish with further
> specification of prefix reachable? What requirement would this
> satisfy? For the use case UPA is designed to handle (triggering BGP
> PIC or other local
On Wed, Nov 09, 2022 at 10:55:38AM +, bruno.decra...@orange.com wrote:
> > From: Lsr On Behalf Of David Lamparter
> > I'd rather not do that and just add
> > a sub-TLV for it.
>
> I'm fine to use max_prefix as per RFC 5305 (prefix not considered
> during SPF) as
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE00),
Hi Les,
On Tue, Jul 23, 2019 at 08:29:30PM +, Les Ginsberg (ginsberg) wrote:
> [...] As network-wide convergence depends upon fast propagation of LSP
> changes -
you're losing me between that previous part and the next:
> - which in turn requires consistent flooding rates on all interfaces
