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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 21 April 2017 18:49 UTC

Return-Path: <alexander.okonnikov@gmail.com>
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 BC255129B5A for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 11:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fSHoANmQO3hw for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 11:49:17 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033F6129B74 for <ospf@ietf.org>; Fri, 21 Apr 2017 11:49:17 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id 88so49224227lfr.0 for <ospf@ietf.org>; Fri, 21 Apr 2017 11:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=dNNRjoK2E1mp248eO9+k2b5UhY2tf+ySb1VvPbRxLnw=; b=cMcIjf5Vi+R9gHAHRGo9i/tNMmtxeDbUthZYQLqpr81jexA/RZafN+kjF7z3d5fNfC NNNThZN6x35n0GIM9O0nLt9+Yg46Zs9PtvxvYHWpcix9nWNnz2yM5dCXt4ezPhl8yr0c vxTILhRhR6eYDDr6F7wrg8HccZrgDy7HSu+IWUlFN2+q2zLfRbY72fADu5IHzoBuRQcd Bb/eTtfc48wWXlDwJg77Oz9HSKWaqjzhJ6kT8DVsUtaTbBOV89u3E8HRNN4e4bsee83G gTZ1lBXq1ntK/jBC7lFbvUwvYi+TnLQElbuYyvErFICquj+SBG+dblpMe5Oer7Px4G7i Y9EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=dNNRjoK2E1mp248eO9+k2b5UhY2tf+ySb1VvPbRxLnw=; b=OS9c+QtVAnmA2AgWrlNhrSsaGuLLi++zpsg0PqOgxm2gOkEdPiBDUYY05oSACLlDkH MyafjtdDbsIISYoNMLhMV5QrUa+Yocv8bz4m6kbbw1cL3j+TVsd2gV9miRGysCyYugPG 4LK8qqkNEG0WWkwKljF0DHmYg8wTIdBuSGLr7CJQ5KAQnN3+mk2seYh681byJOcQvXaE zEO3/jSWbwHynLdIkgCvUXulYdaUYzn8pZi8rvESp6KcoEA0VbcVRROZVnP1+JgBKa6v yTed26C2tshJTp7I+TG3Pdpy8KVCq0VrNxn1/pnaiiqDkhcHC3j2PyvbQJh9WNbp7ciY rc+w==
X-Gm-Message-State: AN3rC/7B7i125gCuvayUndPzSG8xh+BIFfizmuKb8oRt8dYZikWBlmPL w9ObmEvLlfnF4w==
X-Received: by 10.46.83.28 with SMTP id h28mr5367421ljb.70.1492800555174; Fri, 21 Apr 2017 11:49:15 -0700 (PDT)
Received: from [10.0.1.2] ([109.248.36.241]) by smtp.gmail.com with ESMTPSA id g65sm1736584ljb.14.2017.04.21.11.49.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 11:49:14 -0700 (PDT)
Date: Fri, 21 Apr 2017 21:34:09 +0300
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: Christian Hopps <chopps@chopps.org>
Cc: Peter Psenak <ppsenak@cisco.com>, Shraddha Hegde <shraddha@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Message-ID: <3d5bfcbe-bf75-4a57-abe9-9fc9acc60776@Spark>
In-Reply-To: <87o9vpu617.fsf@chopps.org>
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> <87o9vpu617.fsf@chopps.org>
X-Readdle-Message-ID: 3d5bfcbe-bf75-4a57-abe9-9fc9acc60776@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58fa542d_6b8b4567_474c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/6qsBnbm8drb6W0aENhWZINnT20c>
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 18:49:20 -0000

Hi Christian,

See inline.

Thank you.

-- Best regards, Alexander Okonnikov

On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <chopps@chopps.org>, wrote:
>
> 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.
Not sure that understood your point. Yes, implementation that supports this feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but will not necessary do so in response to max metric. Former signals that physical/logical link maintenance is planned, latter - that IGP link property is modified (may be due to planned IGP link or IGP process maintenance). Two are not always correlate. Ignorance of IGP topology changes from LSP recalculation perspective could be design intent, and not unsupported feature or deficiency of particular implementation. In some implementations it could be enabled/disabled by configuration knob. So, even with introducing support of link-overload implementation is not obligated to react to IGP topology changes with LSP recalculation. With 'max metric only' approach it is not possible to distinguish whether link metric was increased due to link overload mode, or due to some other reason.
>
> > 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?
Yes, but it is only one of cases. Enabling LDP on link or restarting LDP process, for example, are other viable triggers for 'max metric'. Also, it could be that other usage of 'max metric' will be invented in the future.
>
> Thanks,
> Chris.