Re: [teas-3272bis-design-team] RFC3272bis - comments and proposed text

Adrian Farrel <adrian@olddog.co.uk> Sat, 07 March 2020 22:55 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas-3272bis-design-team@ietfa.amsl.com
Delivered-To: teas-3272bis-design-team@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55A3A1C0A for <teas-3272bis-design-team@ietfa.amsl.com>; Sat, 7 Mar 2020 14:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 J-_NOwQHXcRy for <teas-3272bis-design-team@ietfa.amsl.com>; Sat, 7 Mar 2020 14:55:34 -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 B824A3A1C0B for <teas-3272bis-design-team@ietf.org>; Sat, 7 Mar 2020 14:55:33 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 027MtTBX027439; Sat, 7 Mar 2020 22:55:29 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E79E022044; Sat, 7 Mar 2020 22:55:28 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id D1D8422042; Sat, 7 Mar 2020 22:55:28 +0000 (GMT)
Received: from LAPTOPK7AS653V ([195.166.134.68]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 027MtRJ8017717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Mar 2020 22:55:28 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Daniele Ceccarelli' <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>, teas-3272bis-design-team@ietf.org
References: <AM6PR0702MB3606BC949CD9B12BFA5C1906F0E50@AM6PR0702MB3606.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR0702MB3606BC949CD9B12BFA5C1906F0E50@AM6PR0702MB3606.eurprd07.prod.outlook.com>
Date: Sat, 07 Mar 2020 22:55:27 -0000
Organization: Old Dog Consulting
Message-ID: <0cc101d5f4d3$7ef37960$7cda6c20$@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: AQI2RcW4hvD2gqm96FJi1JQ4F1Ftjqd8yR2Q
Content-Language: en-gb
X-Originating-IP: 195.166.134.68
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-25276.003
X-TM-AS-Result: No--23.750-10.0-31-10
X-imss-scan-details: No--23.750-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25276.003
X-TMASE-Result: 10--23.750100-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbPVY7U3NX8JgDvc/j9oMIgUWedCrEHXal2gd jdyI8F9laTdE2/CyzhppTSGZOnTFnUc6Ey3iXJ3z8sc9oYKBve32+Qpb93PkPQL5ERphs5jZ0u5 faGP8ztQQwyB+6b6a1Kyt264cYeNmddiFpneQNZ/xkn8eupvmjCRasR0vS5NJq2RzHFToRUhNVn RPFPml0FgEm4VwYZaeiFRhPXpg4OSzFEEBhY5PtJU7Bltw5qVLwZy9wGhpvaOvcOJbZ17mDywUt K2Ys2wzSbJoDiOs/AFJvn0ZmcveaCKwwQyQT1bOi3qFkVLH3UACC8zqHvcG2uZAlRR6AIJ70yT1 UGntc0Vu7YR8SqcF2eTyWaGCD5eAH8AvQUBdeePPkG//aAoWCeDTYjejIZTwsR73pvMuk6/5ih3 vHFgxg4fdrVyz/Thkg2wmwfqhfernOtXIf6BS1T88tWbJdbV38A6q6O7uVrWw0EfjpqqTDmhkSw pykoqV+B40/QXrXVyLcBPOySxNY1L+KwgRcYO/JDuWzfvz/MdMkOX0UoduuTTMRkuw8aul+dLVy pC9bVuW1TToGLgL5xE3hYayn5E18w1NuNQpkz43X0+M8lqGUn+ogtHzaKWZI0YrtQLsSUz+8hbm iOLXoHrDPBax7QY8/9vB4pU+9Pk6s+CwDIvtUTKVTrGMDe/DnQkHrAHoKqZAlaCb+zVQH855fK1 WM1v3UGC11PssyrpXA9GxVui16LrW7ERYbI0yj0drvddoWEQwLjM7t3iRoyATiLvsSv4cnXp+NE mZ8z/7Wc6qSDHHoH6YkKB5J7FEZyVGAxnS9GyeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zUc1+O1X9AzE=
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-3272bis-design-team/BIWdxSCNAil6_p7zxJLn7JwWHVM>
Subject: Re: [teas-3272bis-design-team] RFC3272bis - comments and proposed text
X-BeenThere: teas-3272bis-design-team@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <teas-3272bis-design-team.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-3272bis-design-team>, <mailto:teas-3272bis-design-team-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-3272bis-design-team/>
List-Post: <mailto:teas-3272bis-design-team@ietf.org>
List-Help: <mailto:teas-3272bis-design-team-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-3272bis-design-team>, <mailto:teas-3272bis-design-team-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2020 22:55:35 -0000

Thanks Daniele,

Some nice and useful reductions in text. A couple of points for discussion, and one for future action.

I've used your input to create -08 which I will post now.

Best,
Adrian

From: Teas-3272bis-design-team <teas-3272bis-design-team-bounces@ietf.org> On Behalf Of Daniele Ceccarelli
Sent: 04 March 2020 17:39
To: teas-3272bis-design-team@ietf.org
Subject: [teas-3272bis-design-team] RFC3272bis - comments and proposed text

Hi Adrian, all,

Please find below some inputs from my side till section 4 included (from section 5 onwards in the next episode). The version I reviewed is 07.

> Abstract: is traffic engineering even applicable to the Internet? Yes, maybe it is but it’s not limited to it.

That may be true, but *we* are limited to the Internet and fragments of the Internet. We are the IETF 😊

> In many cases the Internet is best effort, isn’t it? And Traffic Engineering
> is used in the transport network.

It's true. And some of the history points at previous elements of TE in transport technologies.
But I think that the only way in which transport TE impinges on "the Internet" is in providing better quality of connectivity for the Internet.
We might dig into this (and in particular the inter-layer aspects), but maybe not in the Abstract.

> I would also say that TE is not limited to IP networks. 

That is true, and I don't think the Internet is defined as only IP networks. But the Abstract needs a little clarity.

> My suggestion for the abstract would be:
>
> OLD
>   This memo describes the principles of Traffic Engineering (TE) in the
>   Internet.  The document is intended to promote better understanding
>   of the issues surrounding traffic engineering in IP networks, and to
>   provide a common basis for the development of traffic engineering
>   capabilities for the Internet.  The principles, architectures, and
>   methodologies for performance evaluation and performance optimization
>   of operational IP networks are discussed throughout this document.
> NEW
>   This memo describes the principles of Traffic Engineering (TE) in the
>   network.  The document is intended to promote better understanding
>   of the issues surrounding traffic engineering at the various layer of the network (from L0 to L3), and to
>   provide a common basis for the development of traffic engineering
>   capabilities for the Internet.  The principles, architectures, and
>   methodologies for performance evaluation and performance optimization
>   of the networks are discussed throughout this document.

Weeeell, I don't much like this. I think we are limited to "the Internet and IP technologies" in the context of the IETF. That is, we are not writing a general description of TE for the whole world, just for the IETF context. So I am left with...

     This document describes the principles of Traffic Engineering (TE) in the
     Internet.  The document is intended to promote better understanding
     of the issues surrounding traffic engineering in IP networks and the networks
     that support IP networking, and to provide a common basis for the development 
     of traffic engineering capabilities for the Internet.  The principles,
     architectures, and methodologies for performance evaluation and performance
     optimization of operational networks are discussed throughout this document.

> Introduction: 
> "However, because a preponderance of Internet traffic tends to
> be originating in one autonomous system and terminating in
> another, this document provides an overview of aspects
> pertaining to inter-domain traffic engineering."
>
> It is clear what an Autonomous System is, but not what a
> domain is. Reading the terminology section there is a
> definition of Inter-domain traffic, which is exactly inter AS.
> Should we use AS or domain? I would use the term domain
> everywhere (not limited to AS) as applicable to all technology.
> Consider that in the case of SDN there could multiple AS under
> the control of the same SDN controller and we can perfectly
> have TE managed by that SDN controller.

This is a good point, but I'm going to park it for now. The change runs through the whole document and needs some context as well. But it's not a global change because sometimes the context is BGP and ASes apply. I don't have time to make the edit before the cut-off. I've recorded the action.

> Section 1.1
> Trying to find something to cut. I think we can survive without these sections:

Good pointers.
I have trimmed but not cut completely.

> I would cut the bold text as well.

[snip]

Yes that's good.

> Section 1.3: usage of columns or dashes would help reading.

Well, the hanging text should format correctly. But I've added colons to help separate the terms from their defining text.

> Section 2: The following is not needed:

[snip]
Yes, that can go.

> Even better…is section 2 needed at all? I would save
> only section 2.6 and make it section 2.

Let's think about that with the next revision. Better to trim with a sharp knife than prune with a chainsaw.

> Section 3 replace entirely (till 3.1 excluded) with: 
> Section 3.1/3.2/3.3/3.4 to be entirely substituted with:

[snip]

That is a really nice reduction in text. Ruthless, but without loss of meaning.

> Section 4.1: I would create an appendix with “Historical TE
> techniques” and more 4.1 there. It’s an interesting reading for
> my personal knowledge but I don’t need it if I want to learn
> how to build a TE network.
>
> 4.2.1 . can’t we consider this historical?
> 4.2.2 – I would drop 4.2 entirely, move 4.2.1 to appendix
>              and 4.2.2. as first item of 4.3.

I think it is a good idea to move the historical information out.
Edits accordingly.

> 4.3.14 Network Virtualization and Abstraction-  (proposed text):

[snip]

Text taken with only edits for language.

> - 4.4 – what about appendix 2 with TE in other SDOs?

Yes good idea.
We can add other SDOs if we want.
And we could probably usefully reduce the ITU-T text.

Best,
Adrian