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

[John Scudder <[e-mail]>]

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://www.rfc-editor.org/materials/abbrev.expansion.txt 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://www.caida.org/catalog/papers/2020_aspath_prepending/aspath_prepending.pdf)
+
+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: