Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Christian Hopps <> Fri, 21 April 2017 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D35DB129548 for <>; Fri, 21 Apr 2017 08:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bglwje-j6PJt for <>; Fri, 21 Apr 2017 08:36:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72C6E129535 for <>; Fri, 21 Apr 2017 08:36:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id A8F7A61187; Fri, 21 Apr 2017 15:36:21 +0000 (UTC)
References: <> <> <> <> <> <> <>
User-agent: mu4e 0.9.19; emacs 25.1.1
From: Christian Hopps <>
To: Alexander Okonnikov <>
Cc: Peter Psenak <>, Shraddha Hegde <>, "Acee Lindem (acee)" <>, "" <>
In-reply-to: <>
Date: Fri, 21 Apr 2017 11:36:20 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 15:36:24 -0000

Alexander Okonnikov <> writes:

>> no argument about the need of area level flooding - Router LSA with
>> the max metric will be flooded within the area.
>> I have read the section 7.2 several times, but I still do not
>> understand what is the purpose of the Link-Overload sub-TLV there.
>> What is the controller going to do when it receives the area scoped
>> Link-Overload sub-TLV and how it is different to the case where the
>> link is advertised in the Router LSA with max-metric in both directions?

> The fact that link metric has been maximized could not be a trigger for
> LSP recalculation. Some implementations consider IGP topology change as
> a trigger for LSP recalculation, but others - don't. Also, max metric

But you have to change the code anyway to make a new TLV work, right? So
what old code does isn't really relevant, unless I misunderstand things.

> itself doesn't tell about exact reason for what link metric was
> increased. It could be result of IGP-LDP synchronization, for example,
> which is irrespective to TE LSPs. From the other hand, when
> head-end/controller receives explicit indication (Link-overload), it
> could interpret it safely as a trigger to reroute LSP, even if
> overloaded link is only link that satisfies constrains (from CSPF
> perspective). Otherwise, increased metric could not be enough reason to
> relax constrains for LSP.

But IGP-LDP synchronization happens when a link initially comes up. Is
the point then of the new TLV to simply avoid this slight delay on
link-up in using the link for TE?