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

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 04 December 2020 03:54 UTC

Return-Path: <jefftant.ietf@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 7E6223A12C7 for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 19:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, MIME_QP_LONG_LINE=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 Iu_GNmGlCM0n for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 19:54:05 -0800 (PST)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 5888C3A0E95 for <lsr@ietf.org>; Thu, 3 Dec 2020 19:54:05 -0800 (PST)
Received: by mail-pf1-x42c.google.com with SMTP id x24so2788834pfn.6 for <lsr@ietf.org>; Thu, 03 Dec 2020 19:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=VMTi1qbr0YqjX+xDNnDaB7+pK63tMDt2TaxoOdUbAgo=; b=YcnHmntfGU+5641uWvF7luozdiM9iO418xxYoHWEZPO3tedVRe7hzvDv2k74rKLOnN v/Mqhg3LOUHy41oUwL3x+Cjqoj4u1LHUtdsGBBOtBzjAqeAHDMAE1vHUNLyOwr/99Ntc W0Yw+2x1BDlzR+FGCFuRm6Vv7YnvDdO5IPQkm9/8PkEuy2ZmbBP5Q9u3PG4jlo64kcZk NgJmIHIIZyzGHnu//6pTi0sJOMz0bApne8Z65TTrdHqvJc50i6ve6v0T3Q7Cl7Gz9Liv t9SRWc+RT9vNSZEbwLdlchexQcIPU0OuYlQPxdIvkW8+tcssAGFFZjVOla/p51Zs6Pxa gYZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=VMTi1qbr0YqjX+xDNnDaB7+pK63tMDt2TaxoOdUbAgo=; b=MjOZTucsy8JoFUqbYueTj04z369MITRQZM8VutyKCgAvfV/O4hanwmAn0vvQHi/B/u TanBJFoGbDsURJSJhxzOS0ltA1KX+1QTKVkChQfgCn+Hph7h+f+rWh8tdO5nRLh1MBJ3 8wYS50MtNuNvg0RoO5rGZXVPwxIZOIVrV1nP8ayucFIXc5wrSvk3CKpqfHyieU4WVJ0z df9c6xoCTxI1bHjC7vBMuO+RrBNRBlIehj78jTUsd1HmBdrzfp/LU2CP7rO9VzlpGIlu nz5HA8agNsAkc9wm+FwZgcTZAN1JlSiGe1kL6FtUzormvu4FmNs0R2dOCHcwxNQHsYLi mjPA==
X-Gm-Message-State: AOAM530h8DvW0tm8DfJKtDb/m5NAmqWcdBVjRPTMZECWgQCe0hUX80Lb a1J8/U2KQN4XbqAonQ4IAMc=
X-Google-Smtp-Source: ABdhPJzQs5oCmg67PeliGUKOl+rDL2/Uy+iKS+n9KmANy1+DMiVZBKiLxQkYwMoaVUO7prD9YTel5A==
X-Received: by 2002:a63:4905:: with SMTP id w5mr5832104pga.124.1607054043921; Thu, 03 Dec 2020 19:54:03 -0800 (PST)
Received: from [192.168.1.12] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id c132sm695487pfc.119.2020.12.03.19.54.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 19:54:02 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-43529CAD-13C8-44F6-ACBD-6917E6DE9FD5"
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 03 Dec 2020 19:54:01 -0800
Message-Id: <250DE4E0-68E7-480D-881F-BAAB86BB220C@gmail.com>
References: <CABNhwV231dN6stCEVE1x91Qzp_TQ7ywxgVtSg7ZPKwdu=K0Z2Q@mail.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>
In-Reply-To: <CABNhwV231dN6stCEVE1x91Qzp_TQ7ywxgVtSg7ZPKwdu=K0Z2Q@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/l-J4pcb5oP1Zr8Ymq_YQ2UN5K4U>
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 03:54:08 -0000

I’m very much in favor of being able to provide a number of technologies that help operators with different requirements and constraints to provide their services in a most optimized way, hence my support for flex-algo, either labeled or not as a technology on the dynamic spectrum of the solution space.
One can achieve similar results on a single topology with a centralized controller, there are trade-offs in either, extremities on either side are counterproductive . 

Regards,
Jeff

> On Dec 3, 2020, at 17:47, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> 
> 
> 
> 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>, 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
> -- 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>