Re: [Teas] AD review of draft-ietf-teas-rfc3272bis-22

[Gyan Mishra <[e-mail]>]

Hi Adrian

These two RFCs maybe sited as well RFC 4594 and RFC 3644.

Regards

Gyan

On Wed, Jun 14, 2023 at 11:10 AM <[e-mail]> wrote:

> Hi Adrian,
>
> On the first point, we may cite RFC3198 which has a good definition entry
> for QoS.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Teas <[e-mail]> De la part de Adrian Farrel
> > Envoyé : mercredi 14 juin 2023 17:00
> > À : 'John Scudder' <[e-mail]>
> > Cc : [e-mail]; 'Vishnu Pavan Beeram' <[e-mail]>
> > Objet : Re: [Teas] AD review of draft-ietf-teas-rfc3272bis-22
> >
> > Thank you for this, John.
> > A very through and useful review.
> >
> > I have posted a new revision (-23) on which we can iterate if
> > necessary.
> >
> > Only a few things caused me to pause...
> >
> > 1. Your suggestion to include a definition for QoS. I trawled the
> > published RFCs and didn't find a definition. It seems that, from as
> > early as RFC905, the IETF knew what it meant!
> > I thought ISO 8473 (RFC 994) might have given me an answer, but it
> > already assumed that it was a term of art.
> > So I looked at the definitions on the InterWeb and found that they
> > are all somewhat derivative of each other.
> > In the end, I fell back on some words from Jerry Ash from way back,
> > and condensed them a bit. It gave me:
> >
> >            A measure of way in which traffic for a particular service
> > is
> >            delivered to satisfy the requirements of that service.
> > QoS
> >            also refers to the mechanisms used within a network to
> > achieve
> >            specific goals for the delivery of traffic for a
> > particular
> >            service.
> >
> > It's not perfect, but Jerry had a 36 page chapter!
> >
> > 2. The discussion of picoseconds.
> > This text is inherited from 3272 and so is at least 21 years old
> > (presumably older). It is intriguing that if current hardware isn't
> > operating at that granularity, then what was the IETF doing talking
> > about it over 20 years ago?
> > While I am slightly reluctant to unpick what was already written, I
> > think your solution of using "less than" and leaving the lower bound
> > unspecified, is the way to go.
> >
> > 3. I've left out CATS.
> > Of course, it is close to my heart, but I don't think it has
> > developed any mechanisms yet.
> >
> > 4. In Section 7 we have:
> >      When considering inter-domain TE with BGP, note that the
> > outbound traffic exit point is controllable,
> >      whereas the interconnection point where inbound traffic is
> > received typically is not.  Therefore, it
> >      is up to each individual network to implement TE strategies that
> > deal with the efficient delivery of
> >      outbound traffic from its customers to its peering points.  The
> > vast majority of TE policy is based
> >      on a "closest exit" strategy, which offloads inter-domain
> > traffic at the nearest outbound peering point
> >      towards the destination AS.  Most methods of manipulating the
> > point at which inbound traffic enters a
> >      are either ineffective, or not accepted in the peering
> > community.
> > You raise questions. They are fine questions. But I don't know the
> > answers!
> > The text here is direct from 3272, so presumably it used to be true.
> > Yet the world moves on.
> >
> > You asked: Was GROW asked for review input?
> > Sadly the cross-WG (or possibly cross WG?) review was not complete.
> > The matrix defeated me.
> > Perhaps IETF last call could also explicitly copy a long list of
> > "interested" working groups and that would catch GROW who could then
> > fix any issues?
> >
> > Cheers,
> > Adrian
> >
> >
> > -----Original Message-----
> > From: John Scudder <[e-mail]>
> > Sent: 03 June 2023 18:02
> > To: Adrian Farrel <[e-mail]>
> > Cc: [e-mail]; Vishnu Pavan Beeram <[e-mail]>
> > Subject: AD review of draft-ietf-teas-rfc3272bis-22
> >
> > Hi Adrian, WG,
> >
> > Thanks for this document.
> >
> > I've supplied my questions and comments in the form of an edited copy
> > of the draft. Minor editorial suggestions I've made in place without
> > further comment, more substantive questions and comments are done in-
> > line and prefixed with "jgs:". You can use your favorite diff tool to
> > review them; I've attached the iddiff output for your convenience if
> > you'd like to use it. I've also pasted a traditional diff below in
> > case you want to use it for in-line reply.
> >
> > Thanks,
> >
> > -John
> >
> >
> > --- draft-ietf-teas-rfc3272bis-22.txt 2023-06-02 16:09:48.000000000
> > -0400
> > +++ draft-ietf-teas-rfc3272bis-22-jgs-comments.txt    2023-06-03
> > 12:56:24.000000000 -0400
> > @@ -269,8 +269,12 @@
> >
> >     *  A form of a pre-planned optimized traffic distribution that is
> >        considered optimal.
> > +--
> > +jgs: perhaps re-word to make the sentence less optimally redundantly
> > +redundant? ;-) (Likely just remove "optimized".)
> > +--
> >
> > -   In the later case, any deviation from the optimum distribution
> > (e.g.,
> > +   In the latter case, any deviation from the optimum distribution
> > (e.g.,
> >     caused by a fiber cut) is reverted upon repair without further
> >     optimization.  However, this form of TE relies upon the notion
> > that
> >     the planned state of the network is optimal.  Hence, in such a
> > mode
> > @@ -324,6 +328,10 @@
> >     can be found in [RFC4655] and [RFC5394].  Standard TE solutions
> > may
> >     cover the mechanisms to distribute and/or enforce policies, but
> >     specific policy definition is generally unspecified.
> > +--
> > +jgs: Wording again. Maybe something like "... definition of specific
> > +policies is left to the network operator"?
> > +--
> >
> >     Path steering is the ability to forward packets using more
> >     information than just knowledge of the next hop.  Examples of
> > path
> > @@ -366,7 +374,7 @@
> >        supported via queuing.  It also includes the matching of a
> > flow
> >        (i.e., flow classification) to a particular set of allocated
> >        resources.  The method of flow classification and granularity
> > of
> > -      resource management is technology specific.  Examples include
> > +      resource management is technology-specific.  Examples include
> >        Diffserv with dropping and remarking [RFC4594], MPLS-TE
> > [RFC3209],
> >        and GMPLS based label switched paths [RFC3945], as well as
> >        controller-based solutions [RFC8453].  This level of resource
> > @@ -434,7 +442,7 @@
> >        Constraint-based routing is applicable to traffic aggregates
> > as
> >        well as flows.  It is a generalization of QoS-based routing.
> >
> > -   Demand side congestion management:  A congestion management
> > scheme
> > +   Demand-side congestion management:  A congestion management
> > scheme
> >        that addresses congestion problems by regulating or
> > conditioning
> >        offered load.
> >
> > @@ -450,7 +458,7 @@
> >  Internet-Draft   Overview and Principles of Internet TE     October
> > 2022
> >
> >
> > -   Hot-spot:  A network element or subsystem which is in a state of
> > +   Hot spot:  A network element or subsystem which is in a state of
> >        congestion.
> >
> >     Inter-domain traffic:  Traffic that originates in one Autonomous
> > @@ -465,6 +473,12 @@
> >     Network survivability:  The capability to provide a prescribed
> > level
> >        of QoS for existing services after a given number of failures
> >        occur within the network.
> > +--
> > +jgs: Funnily enough, "QoS" as a standalone term isn't defined
> > anywhere.
> > +Admittedly it's starred in
> > +https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.rfc-
> > editor.org%2Fmaterials%2Fabbrev.expansion.txt&data=05%7C01%7Cmohamed.
> > boucadair%40orange.com%7C2a8e74237201439394fd08db6ce83f38%7C90c7a20af
> > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638223516975682484%7CUnknown%7CTWFp
> > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > n0%3D%7C3000%7C%7C%7C&sdata=USMFMlNxoRle1gUWaKOj2tWaOKpznxO8KfLoGjbEf
> > 6o%3D&reserved=0 so perhaps
> > +debatable, but I think it deserves definition in this document.
> > +--
> >
> >     Offline traffic engineering:  A traffic engineering system that
> >        exists outside of the network.
> > @@ -547,7 +561,7 @@
> >     must be appropriately determined and configured according to
> >     prevailing policies and service models to resolve resource
> > contention
> >     issues arising from mutual interference between packets
> > traversing
> > -   through the network.  Thus, consideration must be given to
> > resolving
> > +   the network.  Thus, consideration must be given to resolving
> >     competition for network resources between traffic flows belonging
> > to
> >     the same service class (intra-class contention resolution) and
> >     traffic flows belonging to different classes (inter-class
> > contention
> > @@ -572,6 +586,12 @@
> >         structure, network policies, network characteristics, network
> >         constraints, network quality attributes, and network
> > optimization
> >         criteria.
> > +--
> > +jgs: That's a lotta network. I didn't do the edit, but ISTM you
> > could
> > +without loss of clarity write "The network domain context includes
> > +network structure, policies, characteristics, constraints, quality
> > +attributes, and optimization criteria."
> > +--
> >
> >     2.  A problem context defining the general and concrete issues
> > that
> >         TE addresses.  The problem context includes identification,
> > @@ -662,7 +682,7 @@
> >     Packets contend for the use of network resources as they are
> > conveyed
> >     through the network.  A network resource is considered to be
> >     congested if, for an interval of time, the arrival rate of
> > packets
> > -   exceed the output capacity of the resource.  Congestion may
> > result in
> > +   exceeds the output capacity of the resource.  Congestion may
> > result in
> >     some of the arriving packets being delayed or even dropped.
> >
> >
> > @@ -675,6 +695,10 @@
> >
> >
> >     Congestion increases transit delay, delay variation, may lead to
> > +--
> > +jgs: no edit done since I'm not totally sure of your intent, but
> > something
> > +is needed above. Perhaps s/delay, delay/delay and delay/
> > +--
> >     packet loss, and reduces the predictability of network services.
> >     Clearly, congestion is highly undesirable.  Combating congestion
> > at a
> >     reasonable cost is a major objective of Internet TE.
> > @@ -812,6 +836,15 @@
> >     involve the manipulation of parameters associated with routing,
> >     control over tactical capacity acquisition, and control over the
> >     traffic management functions.
> > +--
> > +jgs: You mention "workload" or "traffic workload" in a number of
> > places
> > +in the document. I don't see any definition of what exactly a
> > "workload"
> > +is, or if you mean anything specific by it at all other than
> > "traffic".
> > +This term has specific meaning in other fields of computing, but I'm
> > not
> > +familiar with it being so common in networking that it needs no
> > definition.
> > +Possibly the same could be said about "offered load", although that
> > one,
> > +at least, I think I can define for myself (but maybe I shouldn't
> > have to).
> > +--
> >
> >     The following list of instruments may be applicable to the
> > solution
> >     context of Internet TE.
> > @@ -825,6 +858,11 @@
> >        and control over the placement and allocation of network
> >        resources, as well as control over the mapping or distribution
> > of
> >        traffic onto the infrastructure.
> > +--
> > +jgs: Is there an "of" missing between "control" and "traffic", i.e.
> > should
> > +it be "control of traffic"? If not I think there's some other repair
> > needed
> > +to that clause.
> > +--
> >
> >     *  A set of constraints on the operating environment, the network
> >        protocols, and the TE system itself.
> > @@ -843,7 +881,7 @@
> >
> >
> >     *  A set of administrative control parameters which may be
> > -      manipulated through a configuration management system.  Such
> > +      manipulated through a configuration management system.  Such a
> >        system itself may include a configuration control subsystem, a
> >        configuration repository, a configuration accounting
> > subsystem,
> >        and a configuration auditing subsystem.
> > @@ -881,6 +919,12 @@
> >     *  information contained in router configuration files
> >
> >     *  routing databases
> > +--
> > +jgs: Given that routing tables are often referred to as routing
> > databases
> > +(the "B" in RIB, FIB, etc), I think there's a need to be clearer
> > about
> > +what you mean by "routing databases" above. I guess maybe you mean
> > external
> > +policy databases such as the IRR, the RPKI, etc?
> > +--
> >
> >     *  routing tables
> >
> > @@ -939,7 +983,7 @@
> >            the medium timescale category.  Examples include:
> >
> >            a.  Adjusting routing protocol parameters to route traffic
> > -              away or towards certain segments of the network.
> > +              away from or towards certain segments of the network.
> >
> >            b.  Setting up or adjusting explicitly routed LSPs in MPLS
> >                networks to route traffic trunks away from possibly
> > @@ -978,6 +1022,23 @@
> >            administrators must make based on their specific needs.
> >
> >         *  Short (picoseconds to minutes): This category includes
> > packet
> > +--
> > +jgs: picoseconds are indeed short! Did you decide on one-trillionths
> > of
> > +a second advisedly, or are you just saying "really really short
> > +timescale"? I went down a brief rabbithole of trying to think of any
> > +kind of TE mechanism we have that might conceivably make changes on
> > this
> > +timescale, and I can't. Considering that we don't have network
> > +interfaces that operate this fast yet, and that the timescale is
> > three
> > +orders of magnitude faster than the clock speeds of our control
> > plane and
> > +network processors, it seems rather brash to be making this claim.
> > On
> > +the other hand, if you really want to go for it, why stop with pico-
> > ? Go
> > +for the attoseconds, I say!
> > +
> > +Alternately, you could go with "minutes or less" which can take the
> > +reader as low as they're willing to tolerate.
> > +
> > +("Picoseconds" also appears later, not flagged separately.)
> > +--
> >            level processing functions and events that are recorded on
> > the
> >            order of several round trip times.  It also includes
> > router
> >            mechanisms such as passive and active buffer management.
> > All
> > @@ -986,6 +1047,12 @@
> >            the rate at which traffic is injected into the network.
> > One
> >            of the most popular active queue management schemes,
> >            especially for TCP traffic, is Random Early Detection
> > (RED)
> > +--
> > +jgs: Is RED still "one of the most popular" schemes? It might be, I
> > +simply don't know -- is this something that can be substantiated by
> > a
> > +source? If not, would it be worth changing this to something like "A
> > +well-known active queue management scheme"?
> > +--
> >            [FLJA93].  During congestion (but before the queue is
> > filled),
> >            the RED scheme chooses arriving packets to "mark"
> > according to
> >            a probabilistic algorithm which takes into account the
> > average
> > @@ -1000,7 +1067,7 @@
> >            which is not worse than traditional Tail-Drop (TD) queue
> >            management (drop arriving packets only when the queue is
> >            full).  Importantly, RED reduces the possibility of global
> > -          synchronization where retransmission burst become
> > synchronized
> > +          synchronization where retransmission bursts become
> > synchronized
> >            across the whole network, and improves fairness among
> >
> >
> > @@ -1013,7 +1080,7 @@
> >            different TCP sessions.  However, RED by itself cannot
> > prevent
> >            congestion and unfairness caused by sources unresponsive
> > to
> >            RED, e.g., UDP traffic and some misbehaved greedy
> > connections.
> > -          Other schemes have been proposed to improve the
> > performance
> > +          Other schemes have been proposed to improve performance
> >            and fairness in the presence of unresponsive traffic.
> > Some of
> >            those schemes (such as Longest Queue Drop (LQD) and
> > Dynamic
> >            Soft Partitioning with Random Drop (RND) [SLDC98]) were
> > @@ -1044,6 +1111,13 @@
> >            used for congestion avoidance because dropping or marking
> >            packets before queues actually overflow would trigger
> >            corresponding TCP sources to slow down.
> > +--
> > +jgs: The first bullet tells me all the long/medium policies are
> > reactive.
> > +The second bullet tells me some of the long/medium policies are
> > preventive.
> > +Does this mean that reactive and preventive are not mutually
> > exclusive? In
> > +that case maybe a sentence to say so. Otherwise, maybe some other
> > edit is
> > +called for.
> > +--
> >
> >     3.  Supply-Side Versus Demand-Side Congestion Management Schemes
> >
> > @@ -1145,7 +1219,7 @@
> >         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
> > +       component level characteristics, and network-wide
> >         characteristics.
> >
> >     2.  Modeling, analysis, and simulation are important aspects of
> > @@ -1153,7 +1227,7 @@
> >         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
> > +       network features, attributes, and characteristics.  Network
> >         simulation tools are extremely useful for TE.  Because of the
> >         complexity of realistic quantitative analysis of network
> >         behavior, certain aspects of network performance studies can
> > only
> > @@ -1216,7 +1290,7 @@
> >     term variations in traffic or changing network conditions.  An
> >     example of a time-dependent algorithm is a global centralized
> >     optimizer where the input to the system is a traffic matrix and
> > -   multi-class QoS requirements as described [MR99].  Another
> > example of
> > +   multi-class QoS requirements as described in [MR99].  Another
> > example of
> >     such a methodology is the application of data mining to Internet
> >     traffic [AJ19] which enables the use of various machine learning
> >     algorithms to identify patterns within historically collected
> > @@ -1254,6 +1328,10 @@
> >     predictable traffic variations, state-dependent algorithms may be
> >     applied to increase network efficiency and resilience to adapt to
> > the
> >     prevailing network state.
> > +--
> > +jgs: something's needed between "resilience" and "to adapt" above,
> > but
> > +I'm not sure what. A comma? The word "and"?
> > +--
> >
> >     Event-dependent TE methods can also be used for TE path
> > selection.
> >     Event-dependent TE methods are distinct from time-dependent and
> > @@ -1270,13 +1348,17 @@
> >     size.  Modeling results suggest that event-dependent TE methods
> > could
> >     lead to a reduction in ALB flooding overhead without loss of
> > network
> >     throughput performance [I-D.ietf-tewg-qos-routing].
> > +--
> > +jgs: At minimum expand "LSA" above. As written it's both undefined,
> > and
> > +OSPF-specific.
> > +--
> >
> >  4.2.  Offline Versus Online
> >
> >     Traffic engineering requires the computation of routing plans.
> > The
> >     computation may be performed offline or online.  The computation
> > can
> >     be done offline for scenarios where routing plans need not be
> > -   executed in real-time.  For example, routing plans computed from
> > +   executed in real time.  For example, routing plans computed from
> >     forecast information may be computed offline.  Typically, offline
> >     computation is also used to perform extensive searches on multi-
> >     dimensional solution spaces.
> > @@ -1293,7 +1375,7 @@
> >     Online computation is required when the routing plans must adapt
> > to
> >     changing network conditions as in state-dependent algorithms.
> > Unlike
> >     offline computation (which can be computationally demanding),
> > online
> > -   computation is geared toward relative simple and fast
> > calculations to
> > +   computation is geared toward relatively simple and fast
> > calculations to
> >     select routes, fine-tune the allocations of resources, and
> > perform
> >     load balancing.
> >
> > @@ -1377,6 +1459,10 @@
> >     network topology may be discovered by running a passive instance
> > of
> >     OSPF or IS-IS, or via BGP-LS [RFC7752], to generate a TED (see
> >     Section 5.1.3.14).  The PCE is used to compute a path (see
> > +--
> > +jgs: Thanks for the xref, but maybe also expand TED on first use, or
> > +put it in the glossary.
> > +--
> >     Section 5.1.3.11) based on the TED and available bandwidth, and
> >     further path optimization may be based on requested objective
> >     functions [RFC5541].  When a suitable path has been computed the
> > @@ -1479,7 +1565,7 @@
> >  4.7.  Tactical versus Strategic
> >
> >     Tactical traffic engineering aims to address specific performance
> > -   problems (such as hot-spots) that occur in the network from a
> > +   problems (such as hot spots) that occur in the network from a
> >     tactical perspective, without consideration of overall strategic
> >     imperatives.  Without proper planning and insights, tactical TE
> > tends
> >     to be ad hoc in nature.
> > @@ -1524,6 +1610,12 @@
> >
> >     This subsection reviews a number of IETF activities pertinent to
> >     Internet traffic engineering.
> > +--
> > +jgs: In the time between the WG requesting publication, and now, the
> > +IETF has chartered CATS. Arguably it's too soon to say if it should
> > +be mentioned here (and thus, it shouldn't be) but I thought I'd draw
> > +your attention to it.
> > +--
> >
> >  5.1.1.  IETF TE Mechanisms
> >
> > @@ -1630,7 +1722,7 @@
> >     point>.  The head-end is the IP address of the node where the
> > policy
> >     is instantiated.  The endpoint is the IP address of the
> > destination
> >     of the policy.  The color is an index that associates the SR
> > Policy
> > -   with an intent (e.g., low-latency).
> > +   with an intent (e.g., low latency).
> >
> >     The head-end node is notified of SR Policies and associated SR
> > paths
> >     via configuration or by extensions to protocols such as PCEP
> > @@ -1657,7 +1749,7 @@
> >        route which indicates an SR Policy.
> >
> >     *  Per-flow Steering: Incoming packets match a forwarding array
> > (for
> > -      example, the classic 5-tuple) which indicates an SR Policies.
> > +      example, the classic 5-tuple) which indicates an SR Policy.
> >
> >     *  Policy-based Steering: Incoming packets match a routing policy
> >        which directs them to an SR Policy.
> > @@ -1690,7 +1782,7 @@
> >        flow across multiple access networks simultaneously.
> >
> >     The control plane is used to provide hosts and specific network
> > -   devices with a set or policies that specify which flows are
> > eligible
> > +   devices with a set of policies that specify which flows are
> > eligible
> >     to use the ATSSS service.  The traffic that matches an ATSSS
> > policy
> >     can be distributed among the available access networks following
> > one
> >     of the following four modes.
> > @@ -1772,15 +1864,15 @@
> >     A DetNet application can express its QoS attributes or traffic
> >     behavior using any combination of DetNet functions described in
> > sub-
> >     layers.  They are then distributed and provisioned using well-
> > -   established control and provisioning mechanisms adopted for
> > traffic-
> > +   established control and provisioning mechanisms adopted for
> > traffic
> >     engineering.
> >
> > -   In DetNet, a considerable state information is required to
> > maintain
> > -   per flow queuing disciplines and resource reservation for a large
> > +   In DetNet, a considerable amount of state information is required
> > to maintain
> > +   per-flow queuing disciplines and resource reservation for a large
> >     number of individual flows.  This can be quite challenging for
> >     network operations during network events such as faults, change
> > in
> >     traffic volume or re-provisioning.  Therefore, DetNet recommends
> > -   support for aggregated flows, however, it still requires large
> > amount
> > +   support for aggregated flows, however, it still requires a large
> > amount
> >     of control signaling to establish and maintain DetNet flows.
> >
> >
> > @@ -1836,7 +1928,7 @@
> >     to connect, but also 'when'.  This is useful for applications
> > that
> >     need to perform bulk data transfer and would like to schedule
> > these
> >     transfers during an off-peak hour, for example.
> > -   [I-D.ietf-alto-performance-metrics] introducing network
> > performance
> > +   [I-D.ietf-alto-performance-metrics] introduces network
> > performance
> >     metrics, including network delay, jitter, packet loss rate, hop
> >     count, and bandwidth.  The ALTO server may derive and aggregate
> > such
> >     performance metrics from BGP-LS (see Section 5.1.3.10) or IGP-TE
> > (see
> > @@ -1850,9 +1942,9 @@
> >  Internet-Draft   Overview and Principles of Internet TE     October
> > 2022
> >
> >
> > -   based on network performance criteria.  ALTO WG is evaluating the
> > use
> > +   based on network performance criteria.  The ALTO WG is evaluating
> > the use
> >     of network TE properties while making application decisions for
> > new
> > -   use-cases such as Edge computing and Datacenter interconnect.
> > +   use cases such as Edge computing and Datacenter interconnect.
> >
> >  5.1.2.2.  Network Virtualization and Abstraction
> >
> > @@ -1869,7 +1961,7 @@
> >     Abstraction and Control of TE Networks (ACTN) [RFC8453] defines a
> >     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
> > +   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:
> >
> > @@ -1884,13 +1976,13 @@
> >     *  Presentation to customers of networks as a virtual network via
> >        open and programmable interfaces.
> >
> > -   The ACTN managed infrastructure is built from traffic engineered
> > +   The ACTN managed infrastructure is built from 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 type of
> >     network virtualization seen in ACTN allows customers and
> > applications
> >     (tenants) to utilize and independently control allocated virtual
> > -   network resources as if resources as if they were physically
> > their
> > +   network 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.
> > @@ -1929,6 +2021,11 @@
> >     provide the required service levels as specified by the SLOs.
> > The
> >     concept of an IETF network slice is consistent with an enhanced
> > VPN
> >     (VPN+) [I-D.ietf-teas-enhanced-vpn].
> > +--
> > +jgs: I interrupt this document interview to mention that this
> > paragraph, or
> > +something like it, might be a nice addition to the introductory part
> > of
> > +draft-ietf-teas-ietf-network-slices.
> > +--
> >
> >  5.1.3.  IETF Techniques Used by TE Mechanisms
> >
> > @@ -1943,7 +2040,7 @@
> >     The constraints and requirements may be imposed by the network
> > itself
> >     or by administrative policies.  Constraints may include
> > bandwidth,
> >     hop count, delay, and policy instruments such as resource class
> > -   attributes.  Constraints may also include domain specific
> > attributes
> > +   attributes.  Constraints may also include domain-specific
> > attributes
> >     of certain network technologies and contexts which impose
> >     restrictions on the solution space of the routing function.  Path
> >     oriented technologies such as MPLS have made constraint-based
> > routing
> > @@ -2019,13 +2116,20 @@
> >
> >
> >     There are two use cases for flex-algo: in IP networks
> > -   [I-D.ietf-lsr-ip-flexalgo] and in segment routing networks
> > +   [I-D.ietf-lsr-ip-flexalgo] and in Segment Routing networks
> >     [I-D.ietf-lsr-flex-algo].  In the first case, flex-algo computes
> >     paths to an IPv4 or IPv6 address, in the second case, flex-algo
> >     computes paths to a prefix SID (see Section 5.1.3.12).
> >
> >     There are many use cases where flex-algo can bring big value,
> > such
> >     as:
> > +--
> > +jgs: In the two paragraphs above we have "There are two use cases"
> > and
> > +"there are many use cases". This causes cognitive dissonance. Also,
> > +surely it would be possible to reword "bring big value" even more
> > +elegantly. Off the top of my head (not claiming elegance here),
> > something
> > +like "Examples of where flex-algo could be useful include:"
> > +--
> >
> >     *  Expansion of functionality of IP Performance metrics [RFC5664]
> >        when points of interest could instantiate specific constraint-
> > @@ -2043,11 +2147,15 @@
> >     *  Building of network slices [I-D.ietf-teas-ietf-network-slices]
> >        where particular IETF network slice SLO can be guaranteed by
> > flex-
> >        algo.
> > +--
> > +jgs: The four bullets above aren't up to the level of polish of the
> > rest
> > +of the prose. I haven't proposed a rewrite, but consider one more
> > go-over?
> > +--
> >
> >  5.1.3.2.  RSVP
> >
> > -   RSVP is a soft state signaling protocol [RFC2205].  It supports
> > -   receiver initiated establishment of resource reservations for
> > both
> > +   RSVP is a soft-state signaling protocol [RFC2205].  It supports
> > +   receiver-initiated establishment of resource reservations for
> > both
> >     multicast and unicast flows.  RSVP was originally developed as a
> >     signaling protocol within the Integrated Services framework (see
> >     Section 5.1.1.1) for applications to communicate QoS requirements
> > to
> > @@ -2084,9 +2192,13 @@
> >     installed in the router.
> >
> >     One of the issues with the original RSVP specification was
> > -   Scalability.  This is because reservations were required for
> > micro-
> > +   scalability.  This is because reservations were required for
> > micro-
> >     flows, so that the amount of state maintained by network elements
> >     tends to increase linearly with the number of traffic flows.
> > These
> > +--
> > +jgs: Above, maybe pick either present or past tense and stick with
> > it, I
> > +don't mind which.
> > +--
> >     issues are described in [RFC2961] which also modifies and extends
> >     RSVP to mitigate the scaling problems to make RSVP a versatile
> >     signaling protocol for the Internet.  For example, RSVP has been
> > @@ -2102,6 +2214,9 @@
> >     to conventional IP control plane protocols.  MPLS extends the
> >     Internet routing model and enhances packet forwarding and path
> >     control [RFC3031].
> > +--
> > +jgs: Does the word "advanced" add anything to the above?
> > +--
> >
> >     At the ingress to an MPLS domain, Label Switching Routers (LSRs)
> >     classify IP packets into Forwarding Equivalence Classes (FECs)
> > based
> > @@ -2130,7 +2245,7 @@
> >  Internet-Draft   Overview and Principles of Internet TE     October
> > 2022
> >
> >
> > -   MPLS is a very powerful technology for Internet TE because it
> > +   MPLS is a powerful technology for Internet TE because it
> >     supports explicit LSPs which allow constraint-based routing to be
> >     implemented efficiently in IP networks [AWD2].  The requirements
> > for
> >     TE over MPLS are described in [RFC2702].  Extensions to RSVP to
> > @@ -2141,33 +2256,33 @@
> >
> >     RSVP-TE is a protocol extension of RSVP (Section 5.1.3.2) for
> > traffic
> >     engineering.  The base specification is found in [RFC3209].
> > RSVP-TE
> > -   enables the establishment of traffic engineered MPLS LSPs (TE
> > LSPs),
> > +   enables the establishment of traffic-engineered MPLS LSPs (TE
> > LSPs),
> >     using loose or strict paths, and taking into consideration
> > network
> >     constraints such as available bandwidth.  The extension supports
> >     signaling LSPs on explicit paths that could be administratively
> >     specified, or computed by a suitable entity (such as a PCE,
> >     Section 5.1.3.11) based on QoS and policy requirements, taking
> > into
> >     consideration the prevailing network state as advertised by IGP
> > -   extension for ISIS in [RFC5305], for OSPFV2 in [RFC3630], and for
> > +   extensions for IS-IS in [RFC5305], for OSPFV2 in [RFC3630], and
> > for
> >     OSPFv3 in [RFC5329].  RSVP-TE enables the reservation of
> > resources
> >     (for example, bandwidth) along the path.
> >
> > -   RSVP-TE includes the ability to preempt LSP based on priorities,
> > and
> > +   RSVP-TE includes the ability to preempt LSPs based on priorities,
> > and
> >     uses link affinities to include or exclude links from the paths
> > of
> >     LSPs.  The protocol is further extended to support Fast Reroute
> > (FRR)
> >     [RFC4090], Diffserv [RFC4124], and bidirectional LSPs [RFC7551].
> > -   RSVP-TE extensions for support for GMPLS (see Section 5.1.3.5 are
> > +   RSVP-TE extensions for support for GMPLS (see Section 5.1.3.5)
> > are
> >     specified in [RFC3473].
> >
> >     Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
> >     documented in [RFC4461], and signaling protocol extensions for
> > -   setting up P2MP MPLS TE LSPs via RSVP-TE is defined in [RFC4875]
> > +   setting up P2MP MPLS TE LSPs via RSVP-TE are defined in [RFC4875]
> >     where a P2MP LSP is comprised of multiple source-to-leaf (S2L)
> > sub-
> >     LSPs.  To determine the paths for P2MP LSPs, selection of the
> > branch
> >     points (based on capabilities, network state, and policies) is
> > key.
> >
> >     RSVP-TE has evolved to provide real time dynamic metrics for path
> > -   selection for low latency paths using extensions to ISIS
> > [RFC8570]
> > +   selection for low latency paths using extensions to IS-IS
> > [RFC8570]
> >     and OSPF [RFC7471] based on STAMP [RFC8972] and TWAMP [RFC5357]
> >     performance measurements.
> >
> > @@ -2195,7 +2310,7 @@
> >     (e.g., incoming port or fiber to outgoing port or fiber) as well
> > as
> >     continuing to support packet switching.  GMPLS provides a common
> > set
> >     of control protocols for all of these layers (including some
> > -   technology-specific extensions) each of which has a diverse data
> > or
> > +   technology-specific extensions) each of which has a distinct data
> > or
> >     forwarding plane.  GMPLS covers both the signaling and the
> > routing
> >     part of that control plane and is based on the TE extensions to
> > MPLS
> >     (see Section 5.1.3.3).
> > @@ -2273,7 +2388,7 @@
> >     meter readers.  The instructions received by a meter from a
> > manager
> >     include flow specifications, meter control parameters, and
> > sampling
> >     techniques.  The instructions received by a meter reader from a
> > -   manager include the address of the meter whose date is to be
> > +   manager include the address of the meter whose data are to be
> >     collected, the frequency of data collection, and the types of
> > flows
> >     to be collected.
> >
> > @@ -2304,11 +2419,18 @@
> >     Intermediate System (IS-IS) protocol to support TE, similarly
> >     [RFC3630] specifies TE extensions for OSPFv2 ([RFC5329] has the
> > same
> >     description for OSPFv3).
> > +--
> > +jgs: Why is OSPFv3 stuck inside parentheses like a second-class
> > citizen?
> > +--
> >
> >     The idea of redistribution of TE extensions such as link type and
> > ID,
> >     local and remote IP addresses, TE metric, maximum bandwidth,
> > maximum
> >     reservable bandwidth and unreserved bandwidth, admin group in IGP
> > is
> >     a common for both IS-IS and OSPF.  The information distributed by
> > the
> > +--
> > +jgs: I don't quite know what the sentence above is trying to say so
> > I
> > +can't propose a rewrite, but I think it needs one.
> > +--
> >     IGPs in this way can be used to build a view of the state and
> >     capabilities of a TE network (see Section 5.1.3.14).
> >
> > @@ -2317,19 +2439,34 @@
> >     parameters, OSPFv2 uses Opaque LSA [RFC5250] type 10 (OSPFv3 uses
> >     Intra-Area-TE-LSA) with two top-level TLV (Router Address and
> > Link)
> >     also with Sub-TLVs for that purpose.
> > +--
> > +jgs: The paragraph above is quite hard to parse.
> > +--
> >
> >     IS-IS also uses the Extended IP Reachability TLV (type 135, which
> > -   have the new 32 bit metric) and the TE Router ID TLV (type 134).
> > +   has the new 32 bit metric) and the TE Router ID TLV (type 134).
> >     Those Sub-TLV details are described in [RFC8570] for IS-IS and in
> >     [RFC7471] for OSPFv2 ([RFC5329] for OSPFv3).
> > +--
> > +jgs: I don't know that the tidbit about "the new 32-bit metric" is
> > +the right level of detail for this document; it's also not so very
> > +new any more. For that matter I don't know that the code point
> > values
> > +are needed here, the names should be sufficient, shouldn't they?
> > +
> > +Also the same comment about the odd parenthesization of OSPFv3
> > applies.
> > +--
> >
> >  5.1.3.10.  Link-State BGP
> > +--
> > +jgs: Is there some reason this subsection isn't called "BGP Link-
> > State"?
> > +I mean, the name is a bit unlovely, but still it is the name.
> > +--
> >
> >     In a number of environments, a component external to a network is
> >     called upon to perform computations based on the network topology
> > and
> >     current state of the connections within the network, including TE
> >     information.  This is information typically distributed by IGP
> > -   routing protocols within the network (see Section 5.1.3.9.
> > +   routing protocols within the network (see Section 5.1.3.9).
> >
> >     The Border Gateway Protocol (BGP) (see also Section 7) is one of
> > the
> >     essential routing protocols that glue the Internet together.  BGP
> > @@ -2344,6 +2481,10 @@
> >     Computation Element (PCE, see Section 5.1.3.11), or may be used
> > by
> >     Application-Layer Traffic Optimization (ALTO) servers (see
> >     Section 5.1.2.1).
> > +--
> > +jgs: Perhaps throw a "for example" or "e.g." in to make it clear the
> > list
> > +above isn't limiting, as in "... can be used to construct, for
> > example, ..."
> > +--
> >
> >
> >
> > @@ -2391,12 +2532,30 @@
> >     packet through a controlled set of instructions, called segments,
> > by
> >     prepending the packet with an SR header: a label stack in MPLS
> > case;
> >     a series of 128-bit segment identifiers in the IPv6 case.
> > +--
> > +jgs: I'm not sure what's being said by "steer a packet through a
> > controlled
> > +set of instructions". The instructions aren't controlled, per se.
> > They are
> > +just instructions. And the packet doesn't traverse them (it's not
> > steered
> > +through them). And they aren't a set (which is unordered), they're a
> > list.
> > +Maybe the sentence is trying to say something like "A node steers a
> > packet
> > +using a list of instructions (called "segments"). These are placed
> > in an
> > +SR header, ..."
> > +
> > +For that matter it's probably desirable to mention somewhere that SR
> > is
> > +both an architecture and two instantiations of that architecture,
> > SR-MPLS
> > +and SRv6.
> > +--
> >
> >     Segments are identified by Segment Identifiers (SIDs).  There are
> >     four types of SID that are relevant for TE.
> >
> >     Prefix SID:  Unique within the routing domain used to identify a
> >        prefix.
> > +--
> > +jgs: The sentence above needs repair. I was tempted to just delete
> > +"unique within the routing domain" but perhaps you're trying to get
> > at
> > +something with it.
> > +--
> >
> >     Node SID:  A Prefix SID with the 'N' bit set to identify a node.
> >
> > @@ -2412,17 +2571,22 @@
> >
> >     Binding SID:  A Binding SID has two purposes:
> >
> > -      1.  Used to advertise the mappings of prefixes to SIDs/Labels.
> > +      1.  To advertise the mappings of prefixes to SIDs/Labels.
> >
> > -      2.  Used to advertise a path available for a Forwarding
> > +      2.  To advertise a path available for a Forwarding
> >            Equivalence Class.
> >
> >     A segment can represent any instruction, topological or service-
> >     based, thanks to the MPLS architecture [RFC3031].  Labels can be
> >     looked up in a global context (platform wide) as well as in some
> >     other context (see "context labels" in Section 3 of [RFC5331]).
> > +--
> > +jgs: The "thanks to the MPLS architecture" clause seems out of
> > place,
> > +especially considering that SR has an SRv6 instantiation as well as
> > an
> > +SR-MPLS instantiation. Perhaps just delete it?
> > +--
> >
> > -   The application of "policy" to segment routing can make SR into a
> > TE
> > +   The application of "policy" to Segment Routing can make SR into a
> > TE
> >     mechanism as described in Section 5.1.1.3.
> >
> >  5.1.3.13.  Bit Index Explicit Replication Tree Engineering
> > @@ -2431,8 +2595,8 @@
> >     encapsulation for multicast forwarding that can be used on MPLS
> > or
> >     Ethernet transports.  A mechanism known as Tree Engineering for
> > Bit
> >     Index Explicit Replication (BIER-TE) [I-D.ietf-bier-te-arch]
> > provides
> > -   a component that could be used to build a traffic engineering
> > -   multicast system.  Note well: BIER-TE does not of itself offer
> > +   a component that could be used to build a traffic-engineered
> > +   multicast system.  BIER-TE does not of itself offer
> >     traffic engineering, and the abbreviation "TE" does not, in this
> >     case, refer to traffic engineering.
> >
> > @@ -2452,6 +2616,10 @@
> >     buffers to guarantee the worst case requirements of admitted
> > traffic
> >     and potentially policing and/or rate-shaping mechanisms,
> > typically
> >     done via various forms of queuing.  This level of resource
> > control,
> > +--
> > +jgs: The "this includes" sentence seems like it could use another
> > pass,
> > +starting with but not limited to agreement in number with
> > "implications".
> > +--
> >     while optional, is important in networks that wish to support
> >     congestion management policies to control or regulate the offered
> >     traffic to deliver different levels of service and alleviate
> > @@ -2468,13 +2636,13 @@
> >
> >  5.1.3.14.  Network TE State Definition and Presentation
> >
> > -   The network states that are relevant to the TE need to be stored
> > in
> > +   The network states that are relevant to TE need to be stored in
> >     the system and presented to the user.  The Traffic Engineering
> >     Database (TED) is a collection of all TE information about all TE
> > -   nodes and TE links in the network, which is an essential
> > component of
> > -   a TE system, such as MPLS-TE [RFC2702] and GMPLS [RFC3945].  In
> > order
> > +   nodes and TE links in the network. It is an essential component
> > of
> > +   a TE system, such as MPLS-TE [RFC2702] or GMPLS [RFC3945].  In
> > order
> >     to formally define the data in the TED and to present the data to
> > the
> > -   user with high usability, the data modeling language YANG
> > [RFC7950]
> > +   user, the data modeling language YANG [RFC7950]
> >     can be used as described in [RFC8795].
> >
> >  5.1.3.15.  System Management and Control Interfaces
> > @@ -2488,6 +2656,9 @@
> >     consumption needs to be optimized for the control interface,
> > other
> >     protocols, such as Group Communication for the Constrained
> >     Application Protocol (CoAP) [RFC7390] or gRPC, are available,
> > +--
> > +jgs: It would be desirable to provide a citation for gRPC.
> > +--
> >     especially when the protocol messages are encoded in a binary
> > format.
> >     Along with any of these protocols, the data modeling language
> > YANG
> >     [RFC7950] can be used to formally and precisely define the
> > interface
> > @@ -2502,12 +2673,19 @@
> >
> >     The Internet is dominated by client-server interactions,
> > principally
> >     Web traffic although in the future, more sophisticated media
> > servers
> > +--
> > +jgs: "Principally Web traffic". I guess? This seems a little like a
> > +[citation needed] claim. My impression -- which I haven't attempted
> > to
> > +check -- was that in terms of traffic volume, multimedia in general
> > and
> > +video in particular dominated. If one construes "Web traffic"
> > broadly
> > +enough, maybe these two things would be consistent.
> > +--
> >     may become dominant.  The location and performance of major
> >     information servers has a significant impact on the traffic
> > patterns
> >     within the Internet as well as on the perception of service
> > quality
> >     by end users.
> >
> > -   A number of dynamic load balancing techniques have been devised
> > to
> > +   A number of dynamic load-balancing techniques have been devised
> > to
> >     improve the performance of replicated information servers.  These
> >     techniques can cause spatial traffic characteristics to become
> > more
> >     dynamic in the Internet because information servers can be
> > @@ -2591,6 +2769,11 @@
> >        high risk of network problems caused by human errors.
> > Automation
> >        may entail the incorporation of automatic feedback and
> >        intelligence into some components of the TE system.
> > +--
> > +jgs: The sentence above feels a little like a tautology; in addition
> > +I'm not sure what information "intelligence" adds, it would be
> > desirable
> > +to be even more specific.
> > +--
> >
> >     Scalability:  Public networks continue to grow rapidly with
> > respect
> >        to network size and traffic volume.  Therefore, to remain
> > @@ -2617,7 +2800,7 @@
> >        the system to a particular environment.  It may also be
> > desirable
> >        to have both online and offline TE subsystems which can be
> >        independently enabled and disabled.  TE systems that are used
> > in
> > -      multi-class networks should also have options to support class
> > +      multi-class networks should also have options to support
> > class-
> >        based performance evaluation and optimization.
> >
> >     Visibility:  Mechanisms should exist as part of the TE system to
> > @@ -2677,7 +2860,7 @@
> >     1.  Pure SPF protocols do not take network constraints and
> > traffic
> >         characteristics into account during route selection.  For
> >         example, IGPs always select the shortest paths based on link
> > -       metrics assigned by administrators) so load sharing cannot be
> > +       metrics assigned by administrators, so load sharing cannot be
> >         performed across paths of different costs.  Using shortest
> > paths
> >         to forward traffic may cause the following problems:
> >
> > @@ -2693,7 +2876,7 @@
> >         *  If traffic from a source to a destination exceeds the
> > capacity
> >            of a link along the shortest path, the link (and hence the
> >            shortest path) becomes congested while a longer path
> > between
> > -          these two nodes may be under-utilized
> > +          these two nodes may be under-utilized.
> >
> >         *  The shortest paths from different sources can overlap at
> > some
> >            links.  If the total traffic from the sources exceeds the
> > @@ -2706,9 +2889,13 @@
> >            may result in persistent congestion problems.
> >
> >     2.  The Equal-Cost Multi-Path (ECMP) capability of SPF IGPs
> > supports
> > -       sharing of traffic among equal cost paths between two nodes.
> > +       sharing of traffic among equal-cost paths between two nodes.
> > +--
> > +jgs: I think "between two nodes" could be dropped, it seems oddly
> > +limiting otherwise and doesn't seem to add anything.
> > +--
> >         However, ECMP attempts to divide the traffic as equally as
> > -       possible among the equal cost shortest paths.  Generally,
> > ECMP
> > +       possible among the equal-cost shortest paths.  Generally,
> > ECMP
> >         does not support configurable load sharing ratios among equal
> >         cost paths.  The result is that one of the paths may carry
> >         significantly more traffic than other paths because it may
> > also
> > @@ -2723,7 +2910,7 @@
> >         described in Section 8 may be capable of better control
> > [FT00],
> >         [FT01].
> >
> > -   Because of these limitations, new capabilities are needed to
> > enhance
> > +   Because of these limitations, capabilities are needed to enhance
> >     the routing function in IP networks.  Some of these capabilities
> > are
> >     summarized below.
> >
> > @@ -2753,7 +2940,7 @@
> >        reservable bandwidth attributes of the network links and by
> >        specifying the bandwidth requirements for path selection.
> >
> > -   *  A number of enhancements to the link state IGPs are needed to
> > +   *  A number of enhancements to the link state IGPs
> >        allow them to distribute additional state information required
> > for
> >        constraint-based routing.  The extensions to OSPF are
> > described in
> >        [RFC3630], and to IS-IS in [RFC5305].  Some of the additional
> > @@ -2820,10 +3007,18 @@
> >     An important aspect of the traffic mapping function is the
> > ability to
> >     establish multiple paths between an originating node and a
> >     destination node, and the capability to distribute the traffic
> > -   between the two nodes across the paths according to some
> > policies.  A
> > -   pre-condition for this scheme is the existence of flexible
> > mechanisms
> > +   between the two nodes across the paths according to configured
> > policies.  A
> > +   precondition for this scheme is the existence of flexible
> > mechanisms
> >     to partition traffic and then assign the traffic partitions onto
> > the
> >     parallel paths as noted in [RFC2702].  When traffic is assigned
> > to
> > +--
> > +jgs: RFC 2702 talks about "parallel traffic trunks" and "parallel
> > +label-switched paths". Maybe it would be better to stick with one of
> > +those phrasings if the same thing is meant here, as it seems to be.
> > +"Parallel paths" (without adjective for "path") is somewhat
> > ambiguous.
> > +
> > +(Also 2x more in this paragraph.)
> > +--
> >     multiple parallel paths, it is recommended that special care
> > should
> >     be taken to ensure proper ordering of packets belonging to the
> > same
> >     application (or traffic flow) at the destination node of the
> > parallel
> > @@ -2843,7 +3038,7 @@
> >     Section 2).
> >
> >     When traffic mapping techniques that depend on dynamic state
> > feedback
> > -   (e.g., MATE [MATE] and such like) are used, special care must be
> > +   (e.g., MATE [MATE] and suchlike) are used, special care must be
> >     taken to guarantee network stability.
> >
> >
> > @@ -2871,14 +3066,14 @@
> >
> >     Traffic statistics may be classified according to long-term or
> > short-
> >     term timescales.  Long-term traffic statistics are very useful
> > for
> > -   traffic engineering.  Long-term traffic statistics may
> > periodicity
> > +   traffic engineering.  Long-term traffic statistics may
> > periodically
> >     record network workload (such as hourly, daily, and weekly
> > variations
> >     in traffic profiles) as well as traffic trends.  Aspects of the
> >     traffic statistics may also describe class of service
> > characteristics
> >     for a network supporting multiple classes of service.  Analysis
> > of
> >     the long-term traffic statistics may yield other information such
> > as
> > -   busy hour characteristics, traffic growth patterns, persistent
> > -   congestion problems, hot-spot, and imbalances in link utilization
> > +   busy-hour characteristics, traffic growth patterns, persistent
> > +   congestion problems, hot spot, and imbalances in link utilization
> >     caused by routing anomalies.
> >
> >     A mechanism for constructing traffic matrices for both long-term
> > and
> > @@ -2920,11 +3115,15 @@
> >        must be aware of the planned traffic volumes and available
> >        resources.  However, this approach is only of value if the
> > traffic
> >        is presented conformant to the planned traffic volumes.
> > +--
> > +jgs: For the last sentence, perhaps something like "... is only of
> > value
> > +if the traffic that is presented conforms to the planned traffic
> > volumes"?
> > +--
> >
> >     *  Traffic flows may be policed at the edges of a network.  This
> > is a
> >        simple way to check that the actual traffic volumes are
> > consistent
> >        with the planned volumes.  Some form of measurement (see
> > -      Section 6.4) is used to determine the rate of arrival of
> > traffic
> > +      Section 6.4) is used to determine the rate of arrival of
> > traffic,
> >        and excess traffic could be discarded.  Alternatively, excess
> >        traffic could be forwarded as best-effort within the network.
> >        However, this approach is only completely effective if the
> > @@ -2951,14 +3150,14 @@
> >     accomplished by promptly recovering from network impairments and
> >     maintaining the required QoS for existing services after
> > recovery.
> >     Survivability is an issue of great concern within the Internet
> > -   community due to the demand to carry mission critical traffic,
> > real-
> > +   community due to the demand to carry mission-critical traffic,
> > real-
> >     time traffic, and other high priority traffic over the Internet.
> >     Survivability can be addressed at the device level by developing
> >     network elements that are more reliable; and at the network level
> > by
> >     incorporating redundancy into the architecture, design, and
> > operation
> >     of networks.  It is recommended that a philosophy of robustness
> > and
> >     survivability should be adopted in the architecture, design, and
> > -   operation of TE that control IP networks (especially public IP
> > +   operation of TE used to control IP networks (especially public IP
> >     networks).  Because different contexts may demand different
> > levels of
> >     survivability, the mechanisms developed to support network
> >     survivability should be flexible so that they can be tailored to
> > @@ -2980,11 +3179,18 @@
> >     The impact of service outages varies significantly for different
> >     service classes depending on the duration of the outage which can
> >     vary from milliseconds (with minor service impact) to seconds
> > (with
> > -   possible call drops for IP telephony and session time-outs for
> > -   connection oriented transactions) to minutes and hours (with
> > -   potentially considerable social and business impact).  Different
> > -   duration outages have different impacts depending on the
> > throughput
> > +   possible call drops for IP telephony and session timeouts for
> > +   connection-oriented transactions) to minutes and hours (with
> > +   potentially considerable social and business impact).  Outages of
> > different
> > +   duration have different impacts depending on the throughput
> >     of the traffic flows that are interrupted.
> > +--
> > +jgs: The final sentence (after my edit, still) seems odd to me. It's
> > in
> > +one sense quite specific (you talk about "throughput" and not
> > various other
> > +qualities such as volume, for instance) and on the other hand rather
> > vague.
> > +I would think that "nature" would fit better than "throughput" with
> > the
> > +sentence's level of abstraction.
> > +--
> >
> >     Failure protection and restoration capabilities are available in
> >     multiple layers as network technologies have continued to evolve.
> > @@ -2999,14 +3205,14 @@
> >     and node outages.  Rerouting at the IP layer occurs after a
> > period of
> >     routing convergence which may require seconds to minutes to
> > complete.
> >     Path-oriented technologies such as MPLS ([RFC3469]) can be used
> > to
> > -   enhance the survivability of IP networks in a potentially cost
> > +   enhance the survivability of IP networks in a potentially cost-
> >     effective manner.
> >
> >     An important aspect of multi-layer survivability is that
> > technologies
> >     at different layers may provide protection and restoration
> >     capabilities at different granularities in terms of time scales
> > and
> > -   at different bandwidth granularity (from packet-level to
> > wavelength
> > -   level).  Protection and restoration capabilities can also be
> > +   at different bandwidth granularity (from the level of packets to
> > that of
> > +   wavelengths).  Protection and restoration capabilities can also
> > be
> >     sensitive to different service classes and different network
> > utility
> >     models.  Coordinating different protection and restoration
> >     capabilities across multiple layers in a cohesive manner to
> > ensure
> > @@ -3028,7 +3234,7 @@
> >
> >     *  Protection and restoration capabilities from different layers
> >        should be coordinated to provide network survivability in a
> > -      flexible and cost effective manner.  Avoiding duplication of
> > +      flexible and cost-effective manner.  Avoiding duplication of
> >        functions in different layers is one way to achieve the
> >        coordination.  Escalation of alarms and other fault indicators
> >        from lower to higher layers may also be performed in a
> > coordinated
> > @@ -3042,7 +3248,7 @@
> >        protection/restoration functions in many layers may increase
> >        redundancy and robustness, but it can result in significant
> >        inefficiencies in network resource utilization.  Careful
> > planning
> > -      is needed to balance the trade-off between the desire for
> > +      is needed to balance the tradeoff between the desire for
> >        survivability and the optimal use of resources.
> >
> >     *  It is generally desirable to have protection and restoration
> > @@ -3060,7 +3266,7 @@
> >
> >     Because MPLS is path-oriented, it has the potential to provide
> > faster
> >     and more predictable protection and restoration capabilities than
> > -   conventional hop by hop routed IP systems.  Protection types for
> > MPLS
> > +   conventional hop-by-hop routed IP systems.  Protection types for
> > MPLS
> >     networks can be divided into four categories.
> >
> >     *  Link Protection: The objective of link protection is to
> > protect an
> > @@ -3197,7 +3403,7 @@
> >  6.8.  Traffic Engineering in Diffserv Environments
> >
> >     Increasing requirements to support multiple classes of traffic in
> > the
> > -   Internet, such as best effort and mission critical data, calls
> > for IP
> > +   Internet, such as best effort and mission critical data, call for
> > IP
> >     networks to differentiate traffic according to some criteria and
> > to
> >     give preferential treatment to certain types of traffic.  Large
> >     numbers of flows can be aggregated into a few behavior aggregates
> > @@ -3231,7 +3437,7 @@
> >     service class.  Such relationships between demand and resource
> >     allocation can be enforced using a combination of, for example:
> >
> > -   *  TE mechanisms on a per service class basis that enforce the
> > +   *  TE mechanisms on a per-service class basis that enforce the
> >        relationship between the amount of traffic contributed by a
> > given
> >        service class and the resources allocated to that class.
> >
> > @@ -3239,9 +3445,9 @@
> >        given service class to relate to the amount of traffic
> > contributed
> >        by that service class.
> >
> > -   It may also be desirable to limit the performance impact of high
> > -   priority traffic on relatively low priority traffic.  This can be
> > -   achieved, for example, by controlling the percentage of high
> > priority
> > +   It may also be desirable to limit the performance impact of high-
> > +   priority traffic on relatively low-priority traffic.  This can be
> > +   achieved, for example, by controlling the percentage of high-
> > priority
> >
> >
> >
> > @@ -3252,21 +3458,21 @@
> >
> >     traffic that is routed through a given link.  Another way to
> >     accomplish this is to increase link capacities appropriately so
> > that
> > -   lower priority traffic can still enjoy adequate service quality.
> > +   lower-priority traffic can still enjoy adequate service quality.
> >     When the ratio of traffic workload contributed by different
> > service
> >     classes varies significantly from router to router, it may not be
> >     enough to rely on conventional IGP routing protocols or on TE
> >     mechanisms that are not sensitive to different service classes.
> >     Instead, it may be desirable to perform TE, especially routing
> > -   control and mapping functions, on a per service class basis.  One
> > way
> > +   control and mapping functions, on a per-service class basis.  One
> > way
> >     to accomplish this in a domain that supports both MPLS and
> > Diffserv
> > -   is to define class specific LSPs and to map traffic from each
> > class
> > +   is to define class-specific LSPs and to map traffic from each
> > class
> >     onto one or more LSPs that correspond to that service class.  An
> > LSP
> >     corresponding to a given service class can then be routed and
> > -   protected/restored in a class dependent manner, according to
> > specific
> > +   protected/restored in a class-dependent manner, according to
> > specific
> >     policies.
> >
> > -   Performing TE on a per class basis may require per-class
> > parameters
> > +   Performing TE on a per-class basis may require per-class
> > parameters
> >     to be distributed.  It is common to have some classes share some
> >     aggregate constraints (e.g., maximum bandwidth requirement)
> > without
> >     enforcing the constraint on each individual class.  These classes
> > can
> > @@ -3310,17 +3516,29 @@
> >     with routing protocols provide finer-grained control, but this
> >     approach is difficult to use and imprecise because of the way the
> >     routing protocols interact occur across the network.
> > +--
> > +jgs: some repair is needed to "routing protocols interact occur
> > across
> > +the network"
> > +--
> >
> >     Control mechanisms can be manual (e.g., static configuration),
> > -   partially-automated (e.g., scripts), or fully-automated (e.g.,
> > policy
> > +   partially-automated (e.g., scripts), or fully-automated (e.g.,
> > policy-
> >     based management systems).  Automated mechanisms are particularly
> > -   useful in large scale networks.  Multi-vendor interoperability
> > can be
> > +   useful in large-scale networks.  Multi-vendor interoperability
> > can be
> >     facilitated by standardized management systems (e.g., YANG
> > models) to
> >     support the control functions required to address TE objectives.
> > +--
> > +jgs: surely a YANG model is a data model, and a data model is not
> > the same
> > +thing as a management system?
> > +--
> >
> >     Network control functions should be secure, reliable, and stable
> > as
> >     these are often needed to operate correctly in times of network
> >     impairments (e.g., during network congestion or security
> > attacks).
> > +--
> > +jgs: surely all attacks are "security attacks", to the extent that a
> > +security attack is a thing at all? Probably delete "security".
> > +--
> >
> >  7.  Inter-Domain Considerations
> >
> > @@ -3331,22 +3549,44 @@
> >     BGP [RFC4271] is the standard exterior gateway protocol used to
> >     exchange routing information between autonomous systems (ASes) in
> > the
> >     Internet.  BGP includes a sequential decision process that
> > calculates
> > +--
> > +jgs: I'm not sure what work "sequential" is doing there. I suggest
> > +deleting it.
> > +--
> >     the preference for routes to a given destination network.  There
> > are
> >     two fundamental aspects to inter-domain TE using BGP:
> >
> >     *  Route Redistribution: Controlling the import and export of
> > routes
> >        between ASes, and controlling the redistribution of routes
> > between
> >        BGP and other protocols within an AS.
> > +--
> > +jgs: In my experience "route redistribution" generally refers to the
> > +second thing you name, moving a route from one protocol to another.
> > I
> > +haven't heard route advertisement policy referred to as
> > "redistribution".
> > +I guess both can be broadly lumped together under the general rubric
> > of
> > +route propagation.
> > +--
> >
> > -   *  Best path selection: Selecting the best path when there are
> > +   *  Best-path selection: Selecting the best path when there are
> >        multiple candidate paths to a given destination network.  This
> > is
> >        performed by the BGP decision process, selecting preferred
> > exit
> >        points out of an AS towards specific destination networks
> > taking a
> >        number of different considerations into account.  The BGP path
> >        selection process can be influenced by manipulating the
> > attributes
> > -      associated with the process, including NEXT-HOP, WEIGHT,
> > LOCAL-
> > -      PREFERENCE, AS-PATH, ROUTE-ORIGIN, MULTI-EXIT-DESCRIMINATOR
> > (MED),
> > -      IGP METRIC, etc.
> > +      associated with the process, including NEXT_HOP, LOCAL_PREF,
> > +      AS_PATH, ORIGIN, MULTI_EXIT_DISC (MED),
> > +      IGP metric, etc.
> > +--
> > +jgs: this isn't quite the right summary of what the decision process
> > does,
> > +it doesn't only select preferred exit points from an AS, it also
> > selects
> > +routes even if they don't exit the AS, for instance. Perhaps I'm
> > obsessing
> > +over precision here because of my personal history, though -- given
> > that
> > +this is a section on *Inter-Domain* considerations, perhaps this is
> > an
> > +acceptable oversimplification.
> > +
> > +I deleted WEIGHT since it's not part of the standard, and corrected
> > the
> > +other capitalized terms to match their names in the standard.
> > +--
> >
> >     Route-maps provide the flexibility to implement complex BGP
> > policies
> >     based on pre-configured logical conditions.  They can be used to
> > @@ -3365,6 +3605,22 @@
> >     logical expressions that implement various types of policies can
> > be
> >     implemented using a combination of Route-maps, BGP-attributes,
> >     Access-lists, and Community attributes.
> > +--
> > +jgs: Both route maps and access lists are peculiar to one vendor's
> > +implementation, they aren't standardized. I don't think there's a
> > simple
> > +term swap-out that fixes this. Perhaps a full paragraph rewrite
> > could look
> > +like,
> > +
> > +NEW:
> > +   Most BGP implementations provide constructs that facilitate the
> > +   implementation of complex BGP policies based on pre-configured
> > +   logical conditions. These can be used to control import and
> > +   export of incoming and outgoing routes, control redistribution of
> > +   routes between BGP and other protocols, and influence the
> > selection
> > +   of best paths by manipulating the attributes (either
> > standardized,
> > +   or local to the implementation) associated with the BGP decision
> > +   process.
> > +--
> >
> >     When considering inter-domain TE with BGP, note that the outbound
> >     traffic exit point is controllable, whereas the interconnection
> > point
> > @@ -3376,6 +3632,16 @@
> >     nearest outbound peering point towards the destination AS.  Most
> >     methods of manipulating the point at which inbound traffic enters
> > a
> >     are either ineffective, or not accepted in the peering community.
> > +--
> > +jgs: the last two sentences above seem to be [citation needed]. In
> > +particular, I had thought AS_PATH prepending was a pretty common
> > +practice. A very brief web search turned up a 2020 CAIDA paper that
> > +seems to confirm this
> > +(https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > ww.caida.org%2Fcatalog%2Fpapers%2F2020_aspath_prepending%2Faspath_pre
> > pending.pdf&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C2a8e74237
> > 201439394fd08db6ce83f38%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> > 638223516975682484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B%2F
> > 6G34T0gWKhNW4yLetJ1xqOHJdxt9eeyycfFldkkvE%3D&reserved=0)
> > +
> > +At this point it occurs to me to ask whether the GROW WG was
> > prompted
> > +to review this section?
> > +--
> >
> >     Inter-domain TE with BGP is generally effective, but it is
> > usually
> >     applied in a trial-and-error fashion because a TE system usually
> > only
> > @@ -3430,6 +3696,9 @@
> >     aspects into account: location of and new links or nodes,
> > existing
> >     and predicted traffic patterns, costs, link capacity, topology,
> >     routing design, and survivability.
> > +--
> > +jgs: Is "location of and new links" supposed to say "any" instead of
> > "and"?
> > +--
> >
> >     Performance optimization of operational networks is usually an
> >     ongoing process in which traffic statistics, performance
> > parameters,
> > @@ -3458,9 +3727,13 @@
> >     the network administrator specifies the destination node and the
> >     attributes of the LSP which indicate the requirements that are to
> > be
> >     satisfied during the path selection process.  The attributes may
> > -   include and explicit path for the LSP to follow, or originating
> > +   include an explicit path for the LSP to follow, or originating
> >     router uses a local constraint-based routing process to compute
> > the
> >     path of the LSP.  RSVP-TE is used as a signaling protocol to
> > +--
> > +jgs: the "or originating router uses" clause seems to need some
> > +adjustment.
> > +--
> >     instantiate the LSPs.  By assigning proper bandwidth values to
> > links
> >     and LSPs, congestion caused by uneven traffic distribution can be
> >     avoided or mitigated.
> > @@ -3474,12 +3747,12 @@
> >  Internet-Draft   Overview and Principles of Internet TE     October
> > 2022
> >
> >
> > -   The bandwidth attributes of an LSP relates to the bandwidth
> > +   The bandwidth attributes of an LSP relate to the bandwidth
> >     requirements of traffic that flows through the LSP.  The traffic
> >     attribute of an LSP can be modified to accommodate persistent
> > shifts
> >     in demand (traffic growth or reduction).  If network congestion
> > -   occurs due to some unexpected events, existing LSPs can be
> > rerouted
> > -   to alleviate the situation or network administrator can configure
> > new
> > +   occurs due to unexpected events, existing LSPs can be rerouted
> > +   to alleviate the situation, or the network administrator can
> > configure new
> >     LSPs to divert some traffic to alternative paths.  The reservable
> >     bandwidth of the congested links can also be reduced to force
> > some
> >     LSPs to be rerouted to other paths.  A traffic matrix in an MPLS
> > @@ -3495,17 +3768,17 @@
> >     computation on behalf of network routers have given way to an
> >     approach that follows the SDN architecture.  A stateful PCE is
> > able
> >     to track all of the LSPs in the network and can redistribute them
> > to
> > -   make better use of the available resources.  Such a PCE can forms
> > +   make better use of the available resources.  Such a PCE can form
> >     part of a network orchestrator that uses PCEP or some other
> >     southbound interface to instruct the signaling protocol or
> > directly
> >     program the routers.
> >
> > -   Segment routing leverages a centralized TE controller and either
> > an
> > +   Segment Routing leverages a centralized TE controller and either
> > an
> >     MPLS or IPv6 forwarding plane, but does not need to use a
> > signaling
> >     protocol or management plane protocol to reserve resources in the
> >     routers.  All resource reservation is logical within the
> > controller,
> >     and not distributed to the routers.  Packets are steered through
> > the
> > -   network using segment routing, and this may have configuration
> > and
> > +   network using Segment Routing, and this may have configuration
> > and
> >     operational scaling benefits.
> >
> >     As mentioned in Section 7, there is usually no direct control
> > over
> > @@ -3515,10 +3788,14 @@
> >     network, maintaining the ability to operate the network in a
> > regional
> >     fashion where desired, while continuing to take advantage of the
> >     benefits of a global network, also becomes an important
> > objective.
> > +--
> > +jgs: I can't figure out what the "When operating a global
> > network..."
> > +sentence is trying to tell me.
> > +--
> >
> >     Inter-domain TE with BGP begins with the placement of multiple
> >     peering interconnection points that are in close proximity to
> > traffic
> > -   sources/destination, and offer lowest cost paths across the
> > network
> > +   sources/destination, and offer lowest-cost paths across the
> > network
> >     between the peering points and the sources/destinations.  Some
> >     location-decision problems that arise in association with inter-
> >     domain routing are discussed in [AWD5].
> > @@ -3549,7 +3826,7 @@
> >     When there are multiple exit points toward a given peer, and only
> > one
> >     of them is congested, it is not necessary to shift traffic away
> > from
> >     the peer entirely, but only from the one congested connections.
> > This
> > -   can be achieved by using passive IGP-metrics, AS-path filtering,
> > or
> > +   can be achieved by using passive IGP metrics, AS_PATH filtering,
> > or
> >     prefix filtering.
> >
> >  9.  Security Considerations
> > @@ -3557,7 +3834,7 @@
> >     This document does not introduce new security issues.
> >
> >     Network security is, of course, an important issue.  In general,
> > TE
> > -   mechanisms are security neutral: they may use tunnels which can
> > +   mechanisms are security-neutral: they may use tunnels which can
> >     slightly help protect traffic from inspection and which, in some
> >     cases, can be secured using encryption; they put traffic onto
> >     predictable paths within the network that may make it easier to
> > find
> > @@ -3576,7 +3853,7 @@
> >
> >     Certain aspects of a network may be deduced from the details of
> > the
> >     TE paths that are used.  For example, the link connectivity of
> > the
> > -   network, and the quality and load on individual links may be
> > assumed
> > +   network, and the quality and load on individual links may be
> > inferred
> >     from knowing the paths of traffic and the requirements they place
> > on
> >
> >
> > @@ -3603,6 +3880,11 @@
> >     Much of the text in this document is derived from RFC 3272.  The
> >     authors of this document would like to express their gratitude to
> > all
> >     involved in that work.  Although the source text has been edited
> > in
> > +--
> > +jgs: Given there's just one front-page author, is the plural
> > accurate?
> > +Granted Adrian is the *editor* and perhaps he is speaking on behalf
> > of
> > +everyone who contributed, so do as you will.
> > +--
> >     the production of this document, the original authors should be
> >     considered as Contributors to this work.  They were:
> >
> >
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .ietf.org%2Fmailman%2Flistinfo%2Fteas&data=05%7C01%7Cmohamed.boucadai
> > r%40orange.com%7C2a8e74237201439394fd08db6ce83f38%7C90c7a20af34b40bfb
> > c48b9253b6f5d20%7C0%7C0%7C638223516975682484%7CUnknown%7CTWFpbGZsb3d8
> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > 3000%7C%7C%7C&sdata=mbvhb%2B%2FXZrun32eTeOLBvulbf%2FiePsgjtECvj%2BHf6
> > WQ%3D&reserved=0
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*