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

Adrian Farrel <adrian@olddog.co.uk> Fri, 04 December 2020 11:41 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB943A0B6C; Fri, 4 Dec 2020 03:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 tMi3DWEpn601; Fri, 4 Dec 2020 03:41:09 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169ED3A0B68; Fri, 4 Dec 2020 03:41:08 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B4Bf3gW013429; Fri, 4 Dec 2020 11:41:03 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A88722042; Fri, 4 Dec 2020 11:41:03 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 854F32203C; Fri, 4 Dec 2020 11:41:03 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.113.187.83]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B4Bf2Mn002672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 11:41:02 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dhruv.ietf@gmail.com>, 'TEAS WG' <teas@ietf.org>, draft-ietf-teas-rfc3272bis@ietf.org
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> <CAB75xn48waYZJ8nGP8ErUTc-pmV2p_=iB4gjbzDLcfNgufP4Zw@mail.gmail.com>
In-Reply-To: <CAB75xn48waYZJ8nGP8ErUTc-pmV2p_=iB4gjbzDLcfNgufP4Zw@mail.gmail.com>
Date: Fri, 04 Dec 2020 11:41:02 -0000
Organization: Old Dog Consulting
Message-ID: <095201d6ca32$586b7060$09425120$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH8VnFOXLr2+nfgZyr1vMlff0Wn2AIpsSyTAjDsTs0Bc0VtJgG5vPkmAV/2RDWpVHfxYA==
Content-Language: en-gb
X-Originating-IP: 87.113.187.83
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25828.007
X-TM-AS-Result: No--18.926-10.0-31-10
X-imss-scan-details: No--18.926-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25828.007
X-TMASE-Result: 10--18.926300-10.000000
X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbPVY7U3NX8Jg+IfriO3cV8TsrmnnmubT8z0s gWH3flQQYugfvC8+WTjuenIkWjLjp7jAlyhiLbFW2Dbo5O4d8SkEbATG004AD2mycYYiBYyZrdL ep+/IHzJCHEBPPS86XMEpfDg8Eir1qkQi8MSvbgSxPNdUdUH1Wt9E7x96JCb0DO+DX+rUwfZdr3 7dknN8wnd+9cPCmWmIt+HkkkXki83j5TDcxpiybqYL5m1UqCZ61QQ6Jx/fflYvZdzSk87rSdPEI qWieqh3qFJeXOCVNZcneo8mSRf54tZyr678xZ6kY320FnKsuJFR3sGN+j7mNGDsuGaRQoY2GFQ0 OTOvSXV5ymO7YrPLhNw1SWwjG9Xk3KKEFgkp3jLTK3Menen4lluiHQC7x/FTT7zqZowzdpIpRdF wSydj6uNheKThsgCQFRSp3EBOHJseh2nHejoau7sHVDDM5xAP4lzqEpaPQLUgxpLaoQ44sImUyB BpbWbNRtdO6hrTx6yzRoLWnk8b24tZ4DlHrpADDcFFYSBeqVYSUsfu0Jv3SkXZjxMNLVRxChnZ6 2X3DzSuK2CoOfWQDrf31mWPe5MJKJd/YZnhHHcZSUX8zcPGn9Li4HRGFLBZK7lFXR4swlkZWCBC R/UAI7IaahK+7qItpCuXXk3GyJhoqrxe97HpSgCSHRN4FLBrChdI4sLlrjiQdFi6Odm8ySzybVq WyY2Ndto7Nlb/ben7Brv946bj5jG6RLCFf8VyJEFMYGmfGMcHgh3sKJBzPzOzujG/qk8BjrGjRz g3l1BCtsL9MxtUqy5H0AbOLI5+Z1ROaes3PU6eAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5d3 cxkNQP90fJP9eHt
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/n_rTZDbRgl8WP73RQmHI2h__6vk>
Subject: Re: [Teas] [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 11:41:12 -0000

Thanks Dhruv,

I'm certainly open to text suggestions in both cases. (I should post -09 because it has some text on SR policy that might help.)

AFAICS SR Flex Algo is actually two things:
- It is a recognition that you don't necessarily use SPF to determine the next hop when deriving a path.
- It is a way to indicate which algorithm should be used to determine the path for a given packet.
I would imagine that this could be described in, say, four lines of text.

The "partial TE" discussion is "interesting". My opinion (and it's only me, so please disagree) is that talk of "partial TE" is actually not helpful. That is because it gives the flavour of TE without actually being TE. It seems to me that it is better to name the components of TE (Policy, Path steering, Resource management) and, if a system does not use all of these components, the system should be called by the component names. Thus, vanilla SR is a Path Steering solution, etc.

Side note: you can construct a full TE system using SR provided you do:
- central management of resources
- traffic policing at the edges
- policy for traffic classification
- no non-SR traffic
- full explicit paths (or a lot of maths on how packets will flow between segment end points)

The problem with the SR discussion (as I see it) is that SR is a tool not a system. A tool is not TE, but a tool can be used to build a TE system. For example, RSVP-TE is not TE, but it is a tool that can be used to build an MPLS TE system.

Best,
Adrian

-----Original Message-----
From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: 04 December 2020 06:28
To: TEAS WG (teas@ietf.org) <teas@ietf.org>; draft-ietf-teas-rfc3272bis@ietf.org
Subject: Fwd: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi TEAS WG,

An interesting thread at LSR on 'what is TE' in the context of Flex Algo!

Two questions for us -
1. Should we include Flex Algo in RFC3272bis?
2. Should we expand on "partial TE" to accommodate these cases a little better?

Thoughts?

Thanks!
Dhruv

---------- Forwarded message ---------
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Date: Fri, Dec 4, 2020 at 6:48 AM
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
To: Tony Li <tony1athome@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: lsr <lsr@ietf.org>, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>


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