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

[Adrian Farrel <[e-mail]>]

Yeah, thanks Gyan.

 

I’d found those two, but they didn’t contain definitions of QoS. More into details and so forth.

 

Cheers,

Adrian

 

From: Gyan Mishra <[e-mail]> 
Sent: 14 June 2023 16:35
To: [e-mail]
Cc: John Scudder <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Teas] AD review of draft-ietf-teas-rfc3272bis-22

 

 

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] <mailto:[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] <mailto:[e-mail]> > De la part de Adrian Farrel
> Envoyé : mercredi 14 juin 2023 17:00
> À : 'John Scudder' <[e-mail] <mailto:[e-mail]> >
> Cc : [e-mail] <mailto:[e-mail]> ; 'Vishnu Pavan Beeram' <[e-mail] <mailto:[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] <mailto:[e-mail]> >
> Sent: 03 June 2023 18:02
> To: Adrian Farrel <[e-mail] <mailto:[e-mail]> >
> Cc: [e-mail] <mailto:[e-mail]> ; Vishnu Pavan Beeram <[e-mail] <mailto:[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 <http://editor.org> %2Fmaterials%2Fabbrev.expansion.txt&data=05%7C01%7Cmohamed.
> boucadair%40orange.com <http://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 <http://ww.caida.org> %2Fcatalog%2Fpapers%2F2020_aspath_prepending%2Faspath_pre
> pending.pdf&data=05%7C01%7Cmohamed.boucadair%40orange.com <http://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] <mailto:[e-mail]> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org <http://ietf.org> %2Fmailman%2Flistinfo%2Fteas&data=05%7C01%7Cmohamed.boucadai
> r%40orange.com <http://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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/teas

-- 

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

Gyan Mishra

Network Solutions Architect 

Email [e-mail]

M 301 502-1347