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

Christian Hopps <chopps@chopps.org> Fri, 21 April 2017 15:36 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35DB129548 for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bglwje-j6PJt for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:36:22 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6E129535 for <ospf@ietf.org>; Fri, 21 Apr 2017 08:36:22 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A8F7A61187; Fri, 21 Apr 2017 15:36:21 +0000 (UTC)
References: <148786668469.20333.199396876398174521.idtracker@ietfa.amsl.com> <D4F1C502.A346C%acee@cisco.com> <BN3PR05MB27066BF8587D26282B08B579D5180@BN3PR05MB2706.namprd05.prod.outlook.com> <58F9BDF2.4040502@cisco.com> <BN3PR05MB2706DA68D0700949F9268706D51A0@BN3PR05MB2706.namprd05.prod.outlook.com> <58F9EA4B.7060704@cisco.com> <0e8cb635-0d9f-f80a-5221-c1a88f24a194@gmail.com>
User-agent: mu4e 0.9.19; emacs 25.1.1
From: Christian Hopps <chopps@chopps.org>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: Peter Psenak <ppsenak@cisco.com>, Shraddha Hegde <shraddha@juniper.net>, "Acee Lindem \(acee\)" <acee@cisco.com>, "ospf\@ietf.org" <ospf@ietf.org>
In-reply-to: <0e8cb635-0d9f-f80a-5221-c1a88f24a194@gmail.com>
Date: Fri, 21 Apr 2017 11:36:20 -0400
Message-ID: <87o9vpu617.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/c_OMPwNApGIWL1EWB_zHD_DfX2w>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 15:36:24 -0000

Alexander Okonnikov <alexander.okonnikov@gmail.com> 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?

Thanks,
Chris.