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 15:48 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 3FD443A0DB2; Fri, 4 Dec 2020 07:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 KY8HsJuFH-RQ; Fri, 4 Dec 2020 07:48:25 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 BAF153A0DA5; Fri, 4 Dec 2020 07:48:23 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B4FmJq3005289; Fri, 4 Dec 2020 15:48:19 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3680822032; Fri, 4 Dec 2020 15:48:19 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 206802203C; Fri, 4 Dec 2020 15:48:19 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.113.187.83]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0B4FmHND030080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 15:48:18 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Dhruv Dhody'" <dhruv.ietf@gmail.com>
Cc: "'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> <095201d6ca32$586b7060$09425120$@olddog.co.uk> <CAB75xn5Ynoc6r9hDAwyt4+45rTqX7kB4oXB9LdLnOLkU84vJ5w@mail.gmail.com>
In-Reply-To: <CAB75xn5Ynoc6r9hDAwyt4+45rTqX7kB4oXB9LdLnOLkU84vJ5w@mail.gmail.com>
Date: Fri, 4 Dec 2020 15:48:18 -0000
Organization: Old Dog Consulting
Message-ID: <09a501d6ca54$e317f4f0$a947ded0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_09A6_01D6CA54.E3190660"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH8VnFOXLr2+nfgZyr1vMlff0Wn2AIpsSyTAjDsTs0Bc0VtJgG5vPkmAV/2RDUCraq2QQILyDaQqS70S0A=
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-25830.001
X-TM-AS-Result: No--20.188-10.0-31-10
X-imss-scan-details: No--20.188-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25830.001
X-TMASE-Result: 10--20.188500-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbPVY7U3NX8JgZAGtCJE23YgWhfQgHJ/xHvc6 XhB/4Ekz1e1Y2Bbm0DCNBgcDOyuw494V9K8RueK0JSZXbLGlrC1O02mT9li3VP2ZU/fHYSOZLWa PLHPZjKOvC6Q/Yp92kPqHc8t/VObnoZo95oO5GwX0VCHd+VQiHiFceJVsZ+5jK4YqHgCSopUWWg 76IlE/zK3gUTGkzHVCprRzL/kxxvliVWddDWw6xeLbvXwDQz25Oxjb9QQbt+Rj21c8aH+7QyHiO prrZOdULwg1efRTd3mNt9AepqR36RmnVN1AL7t0SMFvyr5L84LzZKDA1/pIrg34XnXcobKrIN/M bXxx+S1RVkRxdHZ4L6RIz4oXrpFw7BZwgCO8L3xzu6riTtYUo0yQ5fRSh265ebe1tfR6TkipNjJ CYN87Ws+yPR+y5PqOzXktcWoEjWouNk4ciCArzfgAhuaFie7SLyiv/vFzEkR/Z0SyQdcmEBVppN bQBK1zQZ6svIellgO33gyTF3VzljGzHcks325JN19PjPJahlIKJM4okvH5XoPh5rwOayN2aTEB9 i4AxDytl3UMVP5IF2ImsZuocUrXZyVGAxnS9GzBjbyj5wYDmlNP9sUAWci6a0TOsL14A2nZmoQc Djmvw2ZCt9Mhc8xJKcBsmBos17CwbAwEDxVgPsLRNemq17Eit3aeg7g/usCe9toQ6h6LE1EtMRG FGDWDGJhd2V/Hz/Eh5AyXWmAqpqliFovyqKD/tFK2ZlPEzxE0I3BVHYDiV1VkJxysad/Iw/hdXh LUIp6xw4bGDA7F5BK4NsSnmcApmEZsnqT9GL6eAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7uuCkWLfFZIJ4apx7yk4BjG5YYt7XgEYseUDL9uXb3uj2sznqksrrn7g==
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/q3oeTfqcMyWf2JcgtKqeZtmaq38>
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 15:48:28 -0000

Thanks Dhruv,

 

Yes, the place to work on “components of TE” and “partial TE” is section 1.2

 

A

 

From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: 04 December 2020 14:34
To: Farrel Adrian <adrian@olddog.co.uk>
Cc: TEAS WG <teas@ietf.org>rg>; draft-ietf-teas-rfc3272bis@ietf.org
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

Hi Adrian,

 

On Fri, Dec 4, 2020 at 5:11 PM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > wrote:

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.)

 

Thanks, -09 looks good. 

 

 

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.

 

Agreed. 

 

 

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.

 

I agree with you regarding your description but I believe that we need to talk about it in the bis document so that we have something concrete to point to when discussing TE or not-TE. 

 

We have two ways to provide some guidance in the document - 

 

- Your suggestion to use TE component names, and not to call it TE when not all components exist. My worry is this could become confusing to describe when all but one component is not supported! SR Policy is not just policy for instance.  

- Give this a name: partial-TE, limited-TE, imperfect-TE, something under the umbrella of TE...( I was hoping the WG would come up with a better term :). 

- Some other approach

 

It would be good to hear from the WG on this.  

 

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.

 

Again, +1 to all this! 

 

BTW the discussion in LSR is about IP flex algo :)

 

Thanks! 

Dhruv

 

 


Best,
Adrian

-----Original Message-----
From: Dhruv Dhody <dhruv.ietf@gmail.com <mailto:dhruv.ietf@gmail.com> > 
Sent: 04 December 2020 06:28
To: TEAS WG (teas@ietf.org <mailto:teas@ietf.org> ) <teas@ietf.org <mailto:teas@ietf.org> >; draft-ietf-teas-rfc3272bis@ietf.org <mailto: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 <mailto: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 <mailto:tony1athome@gmail.com> >, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net> >
Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org> >, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org <mailto: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 <mailto: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 <mailto: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 <mailto:Lsr@ietf.org> 
https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org> 
https://www.ietf.org/mailman/listinfo/lsr