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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Sun, 23 April 2017 20:21 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 4FCC61294DF for <ospf@ietfa.amsl.com>; Sun, 23 Apr 2017 13:21:34 -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 d7lFUQygrvxS for <ospf@ietfa.amsl.com>; Sun, 23 Apr 2017 13:21:32 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 68656126C25 for <ospf@ietf.org>; Sun, 23 Apr 2017 13:21:31 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id 75so64648671lfs.2 for <ospf@ietf.org>; Sun, 23 Apr 2017 13:21:31 -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=OOqhEA8LV33BD/xH8yLYA+9Nnl0fKug8y+3jRrQZZCg=; b=fFhwZ3kZ0GlgWuCN5kg5UaywAYUgEA6nISr0bPz1bEa9T9pD4c0dnAD3Sy/29JWLQ+ tj9EP8rCm9T4D1Euv/JfVcSvfzyTz/qvvzEXC9xpp6WiDLspbiOzFekt9NXApWwxdy0K lpU3nU2UJicfpE0AYMXeV6T5hBxjLzSazw2pnEwHefc3h17BC+bNrOOwkhleAqzwqmiV MrT1LqzJ/GtpJEZ1s4Z47AbaKU0wzs3oonqE1WhBGpKuD0ODD8GQt2yP+kLnCJxBOoGi 3tt9SnIAD1oxu3dG9o+pHe69Wy5rC18v2Vsr7ykgMKjOhEnRaI29ZpIMt85iVzJco+QI 43WQ==
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=OOqhEA8LV33BD/xH8yLYA+9Nnl0fKug8y+3jRrQZZCg=; b=NiiTDPGAKVwho/TKTi7qQ/lxJuiZXGLZdOtaveKk1fsSMr9E0uEBeSKlNzzANMT8u2 70YvzFkv8aauSKjMpsrQ3V5njhllB1ZwGE0zVGPx0qNLpOhITePKGdjFOwUzmgIlFtxY EoFOvlMtmvORZBNmFfgiKSIe9fwVtaPzTTs39YO8vHxcmZYsDdmfBzYuWKZ9T6PAxJZ7 m/X32u5vZ1MxVMSsbXwWAmEWWeEhBAzl4zdO8dvka1qCyZIJjbLNMwbHa7tzTpJ29cG2 SQ5sCS/lKS1amYgmMesm8U1d8pRIbYa2AdOes2C/AB2WODvU3No0oUGQ+ekaUkwu+SHM LKNg==
X-Gm-Message-State: AN3rC/5xGS3/Pz/34Y3O6JcylV8WECtSdtiy6WbI1iv62zz0+M6rlkqr yakm1Yr6qrFHuQ==
X-Received: by 10.46.20.15 with SMTP id u15mr8141265ljd.81.1492978889651; Sun, 23 Apr 2017 13:21:29 -0700 (PDT)
Received: from [10.0.1.2] ([109.248.36.241]) by smtp.gmail.com with ESMTPSA id q84sm2946525lfi.31.2017.04.23.13.21.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Apr 2017 13:21:28 -0700 (PDT)
Date: Sun, 23 Apr 2017 22:22:57 +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>, "=?utf-8?Q?ospf=40ietf.org?=" <ospf@ietf.org>
Message-ID: <6f928cb6-cdbd-42e2-bc18-9c854f38f8c9@Spark>
In-Reply-To: <8737czgnlj.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> <3d5bfcbe-bf75-4a57-abe9-9fc9acc60776@Spark> <8737czgnlj.fsf@chopps.org>
X-Readdle-Message-ID: 6f928cb6-cdbd-42e2-bc18-9c854f38f8c9@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58fd0cc7_6b8b4567_53ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/t9eTg6MA6h5O0nCsC0ICbupFSvA>
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: Sun, 23 Apr 2017 20:21:34 -0000

Hi Christian,

See inline.

Thank you.

On 23 апр. 2017 г., 18:17 +0300, Christian Hopps <chopps@chopps.org>, wrote:
>
> Alexander Okonnikov <alexander.okonnikov@gmail.com> writes:
>
> > 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.
>
> Are these actual scenarios that really matter or would actually be used
> by an operator? Do you know of operators that wish to perform "IGP link
> maintenance" (not sure how that is different from "link maintenance") on
> a link, that doesn't involve simply removing the link from service?
Yes, I has my own experience with migrating IGP for some operator. We migrated from using of single IS-IS instance to multiple instances of IS-IS. As part of migration we was moving IGP links (not IP links themselves) from one instance to another ones. From IGP point of view this is losing and establishing of adjacencies. If other routers trigger RSVP LSP recalculation, their RSVP LSPs would be rerouted around maintained router. Fortunately, the implementation doesn't consider IGP topology changes as a trigger to make RSVP LSPs recalculation, and data plane worked as if there was no IGP maintaining. Notice that re-establishing RSVP LSPs (even with MBB procedure) has some negative effects, like put additional traffic load on some links (detoured traffic), stress CPU on routers, and out-of-ordering (new path is shorter) or delaying (new path is longer) packets.
>
> > 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.
>
> Max-metric is meant to signal "don't use link if at all possible" nothing
> else, there won't be future use that doesn't mean that as well. You're
> adding another TLV to signal the exact same intent. I don't see the need
> is all.
RFC 5443 states that suboptimal IP traffic forwarding is a consequence of using this mechanism. I.e. while we use max-metric to avoid blackholing of traffic on LDP LSPs, we are facing unavoidable side effect in that native IP traffic will be needlessly rerouted as well. If other routers interpret max-metric link as a trigger to resignal RSVP LSPs, drawback of this will impact traffic on latter as well. Thus, max-metric mechanism is multi-purpose and covers several applications. Each time one of applications needs to use 'max-metric', other applications will be impacted as well.

>
> Thanks,
> Chris.
>
> >
> > Thanks,
> > Chris.