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

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 4 Mar 2020 17:39:17 +0000

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. In many cases the Internet is
best effort, isn't it? And Traffic Engineering is used in the transport
network. I would also say that TE is not limited to IP networks. The comment
is applicable to the entire document. 

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.

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

*	Section 1.1

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

Internet traffic engineering responds at different temporal
   resolution to network events.  Certain aspects of capacity
   management, such as capacity planning, respond at very coarse
   temporal levels, ranging from days to possibly years.  The
   introduction of automatically switched optical transport networks
   (e.g., based on GMPLS concepts, see
<https://tools.ietf.org/html/draft-dt-teas-rfc3272bis-07#section-4.3.5>
Section 4.3.5) could
   significantly reduce the lifecycle for capacity planning by
   expediting provisioning of optical bandwidth.  Routing control
   functions operate at intermediate levels of temporal resolution,
   ranging from milliseconds to days.  Finally, the packet level
   processing functions (e.g., rate shaping, queue management, and
   scheduling) operate at very fine levels of temporal resolution,
   ranging from picoseconds to milliseconds while responding to the
   real-time statistical behavior of traffic.

I would cut the bold text as well.

Performance evaluation can be achieved in many different ways.  The
   most notable techniques include analytical methods, simulation, and
   empirical methods based on measurements.  The processs can be quite
   complicated in practical network contexts.  For example, simplifying
   concepts such as effective bandwidth and effective buffer [
<https://tools.ietf.org/html/draft-dt-teas-rfc3272bis-07#ref-ELW95> ELW95]
may
   be used to approximate nodal behaviors at the packet level and
   simplify the analysis at the connection level.  A set of concepts
   known as network calculus [
<https://tools.ietf.org/html/draft-dt-teas-rfc3272bis-07#ref-CRUZ> CRUZ]
based on deterministic bounds may
   simplify network analysis relative to classical stochastic
   techniques.
   In many cases, Internet traffic engineering is about finding the
   least bad action to take to enhance the performance of the network.
   For this, it is necessary to reliably predict the impact of potential
   corrective actions in a networking context.  Such a prediction often
   relies on the accuracy of a simulation model identifying root cause
   and duration of a bottleneck, as well as the effectiveness of
   corrective actions and its side-effects over time.

*	Section 1.3: usage of columns or dahes would help reading.
*	Section 2: The following is not needed:

   The Internet has quickly evolved into a very critical communications
   infrastructure, supporting significant economic, educational, and
   social activities.  Simultaneously, the delivery of Internet
   communications services has become very competitive and end-users are
   demanding very high quality service from their service providers.
   Consequently, performance optimization of large scale IP networks,
   especially public Internet backbones, have become an important
   problem.  Network performance requirements are multi-dimensional,
   complex, and sometimes contradictory; making the traffic engineering
   problem very challenging.

*	Even better.is section 2 needed at all? I would save only section
2.6 and make it section 2.
*	Section 3 replace entirely (till 3.1 excluded) with: 

This section describes a generic process model that captures the high level
practical aspects of Internet traffic engineering in an operational context.
The process model is described as a sequence of  actions that a traffic
engineer, or more generally a traffic engineering system, must perform to
optimize the performance of an operational network (see also [RFC2702],
AWD2]).  This process model may be enacted explicitly or implicitly, by an
automaton and/or by a human.

The traffic engineering process model is iterative [AWD2].  The four  phases
of the process model described below are repeated continually.

1.	Define the relevant  control policies that govern the operation of
the network.
2.	A feedback mechanism involving the acquisition of measurement data
from the operational network.
3.	Analyze the network state  and to characterize traffic workload.
Performance analysis may be proactive and/or reactive.  Proactive
performance analysis identifies

   potential problems that do not exist, but could manifest in the future.
Reactive performance analysis identifies existing problems,  determines
their cause through diagnosis, and valuates alternative  approaches to
remedy the problem, if necessary. 

4.	Performance optimization of the network.  It involves a decision
process which selects and implements a set of actions from a set of
alternatives.  Optimization actions may include

   the use of appropriate techniques to either control the offered  traffic
or to control the distribution of traffic across the network.

*	Section 3.1/3.2/3.3/3.4 to be entirely substituted with:

Section 3.1 Components of the Traffic Engineering Process Model

   The key components of the traffic engineering process model are: 

1.	Measurement: it is crucial to the traffic engineering function.  The
operational state of a network can be conclusively determined only through
measurement.  Measurement is also critical to the optimization function
because it provides feedback data which is used by traffic engineering
control subsystems.  This data is used to adaptively optimize network
performance in response to events and  stimuli originating within and
outside the network. Measurement in support of the TE function can occur at
different levels of abstraction.  For example, measurement can be used to
derive packet level characteristics, flow level characteristics, user or
customer level characteristics, traffic aggregate characteristics, component
level characteristics, and network wide characteristics.

2.	Modeling, Analysis, and Simulation: They are important aspects of
Internet traffic engineering.  Modeling involves constructing an abstract or
physical representation which depicts relevant traffic characteristics and
network attributes.  A network model is an abstract representation of the
network which captures relevant network features, attributes, and
characteristic.  Network simulation tools are extremely useful for traffic
engineering.  Because of the complexity of realistic quantitative analysis
of network behavior, certain aspects of network performance studies can only
be conducted effectively using simulation.  

3.	Optimization: Network performance optimization involves resolving
network issues by  transforming such issues into concepts that enable a
solution, identification of a solution, and implementation of the solution.
Network performance optimization can be corrective or perfective.  In
corrective optimization, the goal is to remedy a problem that has occurred
or that is incipient.  In perfective optimization, the goal is to improve
network performance even when explicit problems do not exist and are not
anticipated.

*	Section 4.1: I would create an appendinx 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.
*	4.3.14 Network Virtualization and Abstraction-  (proposed text):

One of the main drivers for Software-Defined Networking (SDN) [RFC7149] is a
decoupling of the network control plane from the data plane.  This
separation has been achieved for TE networks with the development of
MPLS/GMPLS [RFC3945] and the Path Computation Element  (PCE) [RFC4655].  One
of the advantages of SDN is its logically centralized control regime that
allows a global view of the underlying networks.  Centralized control in SDN
helps improve network resource utilization compared with distributed network
control.  

Abstraction and Control of TE networks (ACTN) [RFC8453] defines an
hierarchical SDN architecture which describes the functional entities and
methods for the coordination of resources across multiple domains, to
provide end-to-end traffic engineered services.

ACTN facilitates end-to-end connections and provides them to the user. ACTN
is focused on aspects like abstraction, virtualization and presentation. In
particular it deals with:

*	Abstraction of the underlying network resources and how they are
provided to higher-layer applications and customers;
*	Virtualization of underlying resources, whose selection criterion is
the allocation of those resources for the customer, application, or service.
The creation of a virtualized environment allowis operators to view and
control multi-domain networks as a single virtualized network.
*	Presentation to customers of networks as a virtual network via open
and programmable interfaces.

The ACTN managed infrastructure are traffic engineered network resources,
which may include Statistical packet bandwidth, physical forwarding plane
sources (such as: wavelengths and time slots), forwarding and cross connect
capabilities.  The ACTN type of network virtualization provides customers
and applications (tenants) to utilise and independently control allocated
virtual network resources as if resources as if they were physically their
own resource. The ACTN network is "sliced", with tenants being given a
different partial and abstracted topology view of the physical underlying
network.

*	4.4 - what about appenix 2 with TE in other SDOs?

Thanks,

Daniele  

Daniele

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Mar 2020 22:55:27 -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 <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: 04 March 2020 17:39
To: [email-masked]
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.

>   of the issues surrounding traffic engineering at the various layer of the network (from L0 to L3), and to

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