Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Gyan Mishra <hayabusagsm@gmail.com> Fri, 04 December 2020 01:47 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE33A0408 for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 17:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 XtiVdra2btbR for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 17:47:55 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 475883A11F8 for <lsr@ietf.org>; Thu, 3 Dec 2020 17:47:55 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id o7so2241114pjj.2 for <lsr@ietf.org>; Thu, 03 Dec 2020 17:47:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UPIEXxDyoX24dsP9bHo1xt9MsLtVbN4ZXJMIYCdh7Aw=; b=lejD+gMYG2Nn1VsE42j83rqQO/SdERYREGM95RieE4yGX9WWK3Jexm2s6G6eE/0BUe V8jaHrROgYdqaBkMCOy42MVaebphVpgdkq8aCoWZSMwRGPw/psOYOZGGkYj2QX4o6Qc1 AGEk+YyvbcxbEMACKHoSjH59ZSVvwWNBrf4R4He4O219AEPbRzmQv2+WoSIpU4QseyQ0 XrvcvzOcs4XiKNNY07wAG9YT5ozmKXK+FTAD+YxKENIryUVoeCan3MuskxDZEt5kOZiE hiGWusVN/pTRegaUAu0VHtuU0DFirsX2r6mPGcJKJBSZQNYKBSs3zSgzVQBqLsW+somT Br+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UPIEXxDyoX24dsP9bHo1xt9MsLtVbN4ZXJMIYCdh7Aw=; b=niisPV5EcSPyl3cBK2V2QPZDWS8A8FlfPv26w1knwtrzQpUuAupEM/K+qunKQuh9gD PN+kVwcxDXn0rSX0floJFIbfbhiYivomw6Obfv2MrDYRXHRB6pY5/gDKgRWNWHL7grSu fzGE5BL7bAOqUa5iY6HVd7BbUTqB8ZMC/Z9qC4scKO1wlLM+xN1mDvfk1oPVDSrw9N6m f2EGnQFjYliXaJ73EQbjT02GK8frQaX117cPZxu/lmjL1LAT4m0kHRTx0jVwvtapzO0h bn47G4lXmecKB8lq/RdvUMb9i8R+JL9rn4CVSyjrmhmITpvOZr3Lo18aUdzpk+az4XWb h6mA==
X-Gm-Message-State: AOAM53221vy7YeMo4Cu59Ukq2pDV7F0q9zS/zWibC4xI10t1PCACn4Fw odAzFqx+D55lguczXS1fWH7yiB4P7TIv3v+1A4o=
X-Google-Smtp-Source: ABdhPJyb6ABgEhqpkyi1gWBBAuyq31O3MfokqU/+PWxQ00GEeYyDiinnnIrL7fsPTd2fJpDiwETstIKKQpAEmDfqako=
X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr1851309pja.132.1607046474487; Thu, 03 Dec 2020 17:47:54 -0800 (PST)
MIME-Version: 1.0
References: <777B2AC4-CACF-4AB0-BFC7-B0CFFA881EEB@cisco.com> <CAOj+MMEmmFfN228okgFGM09qaiB8s0nS_8rQEqwBVsdJidy8XA@mail.gmail.com> <F1AE46BD-5809-467A-9CE1-69C08406CB40@gmail.com> <CAOj+MMED+kWaT8Hr-ohq8U1ADYrcNCQDX-svADzVjbo81urJ8A@mail.gmail.com> <5ec998de-115b-4a0a-818d-5df893082d49@Spark>
In-Reply-To: <5ec998de-115b-4a0a-818d-5df893082d49@Spark>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 3 Dec 2020 20:46:38 -0500
Message-ID: <CABNhwV231dN6stCEVE1x91Qzp_TQ7ywxgVtSg7ZPKwdu=K0Z2Q@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Robert Raszuk <robert@raszuk.net>, Tony Li <tony1athome@gmail.com>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003fdc8105b599aa99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/btnGBO0MFkdT1l_MAP_bEjb60ck>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 01:47:59 -0000

In fact the concept of traffic engineering has been around for a long time
using simple IGP metric manipulation to steer traffic using the IGP.

I had designed in my past life a costing algorithm where you use highest
bandwidth links and lowest latency as the crow flies point A to point B
such that you take the highest bandwidth lowest latency path based on a
formula for path instantiation.  This is the essence of flex algo basically
an engineered algorithm algo xyz for a sub routing instance instantiation.

This concept works well for global table or single routing instance,
however if you have multiple VPNs and you want to realize per VPN coloring
capabilities it is much different then use of flex algo with a single IGP
global table routing following a single algo or multiple sub set algo’s.

That’s where RSVP TE PCALC path computation and bandwidth and link
attributes came into play in an MPLS context.

However, now trying to expand traditional RSVP TE to provide per VRF VPN
mapping and coloring is now a daunting painful and non scalable solution.
Now requires with RSVP static routes and VRF next hop rewrite to map each
VPN to a different color steered statically to a different loopback egress
PE iBGP next hop then the default iBGP global table next hop.

That’s where the advent of SR with SR-TE now fills that much needed gap of
per VRF coloring to build the same as we had in the RSVP world loose path
prefix sid or strict path adjacency sid path instantiation now done via
centralized controller.

The gap where flex algo comes into play is unique but I think is a tool on
the operator toolbox which prior to IP flex algo provided additional
steering granularity and path instantiation control used in conjunction
with SR-TE.

The gap IP flex algo fills is internet providers global table routing being
able to create logical traffic steering constructs where MPLS or SR does
not exist.

So that is a huge much needed gap as not all operators on the public core
have MPLS or SR and would like an alternative.

This could be used in both core and data center space as well IP based
infrastructure.

RSVP TE and SR have their niche and now IP flex algo fills yet another
somewhat mutually exclusive niche.

Kind Regards

Gyan

On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Anything else than IGP metric based SPT is considered TE. Looking
> holistically - topology virtualization (or similar) could have been a
> better name.
>
> Cheers,
> Jeff
> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk <robert@raszuk.net>et>, wrote:
>
> Hi Tony,
>
> The moment I hit "Send" I knew that this response may be coming as it
> really depends what is one's definition of TE.
>
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE
> feature.
>
> However, while a very useful and really cool proposal, my point is to make
> sure this is not oversold - that's all.
>
> Best,
> R.
>
>
> On Fri, Dec 4, 2020 at 1:13 AM Tony Li <tony1athome@gmail.com> wrote:
>
>>
>> Hi Robert,
>>
>>
>> > However I really do not think that what Flexible Algorithm offers can
>> be compared or even called as Traffic Engineering (MPLS or SR).
>> >
>> > Sure Flex Algo can accomplish in a very elegant way with little cost
>> multi topology routing but this is not full TE. It can also direct traffic
>> based on static or dynamic network preferences (link colors, rtt drops etc
>> ... ),  but again it is not taking into account load of the entire network
>> and IMHO has no way of accomplish TE level traffic distribution.
>> >
>> > Just to make sure the message here is proper.
>>
>>
>> It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no
>> bandwidth reservation. There’s no dynamic load balancing. No, it’s not a
>> drop in replacement for RSVP. No, it does not supplant SR-TE and a good
>> controller. Etc., etc., etc….
>>
>> However I don’t feel that it’s fair to say that FlexAlgo can’t be called
>> Traffic Engineering.  After all TE is a very broad topic. Everything that
>> we’ve done that’s more sophisticated than simple SPF falls in the area of
>> Traffic Engineering.  Link coloring and SRLG alone clearly fall into that
>> bucket.
>>
>> I’ll grant you that it may not have the right TE features for your
>> application, but that doesn’t mean that it’s not sufficient for some.
>> Please don’t mislead people by saying that it’s not Traffic Engineering.
>>
>> Regards,
>> Tony
>>
>>
>> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD