Re: [auth48] AUTH48: RFC-to-be 9522 <draft-ietf-teas-rfc3272bis-27> for your review

[[e-mail]]

Adrian,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
-->


2) <!-- [rfced] FYI - While we understand RFC 3272 was published with some of the
text we are questioning below, the questions and edits are aimed at
making the text as correct and useful to the reader as possible.  Please
review carefully.
-->


3) <!-- [rfced] In Section 1.2, would it be helpful to include text to introduce
the second bulleted list? Or is the current okay?
-->


4) <!-- [rfced] Would it be helpful to clarify "via [RFC3209]" and "via
[RFC4203]" here by mentioning the mechanisms in those documents?

Original:
      Such accounting can
      be done based on any combination of a static understanding of
      resource requirements, and the use of dynamic mechanisms to
      collect requirements (e.g., via [RFC3209]) and resource
      availability (e.g., via [RFC4203]).

Perhaps:
      Such accounting can
      be done based on any combination of a static understanding of
      resource requirements and the use of dynamic mechanisms to
      collect requirements (e.g., via RSVP-TE [RFC3209]) and resource
      availability (e.g., via OSPF extensions for GMPLS [RFC4203]).
-->


5) <!-- [rfced] May we update "The offered load or offered traffic load" and "The
workload or traffic workload" in these definitions as follows?

Original:
   Offered load:  The offered load or offered traffic load is a measure
      of the amount of traffic being presented to be carried across a
      network compared to the capacity of the network to carry it.
   ...      
   Workload:  The workload or traffic workload is an evaluation of the
      amount of work that must be done in a network in order to
      facilitate the traffic demand. 

Perhaps: 
   Offered load:  Also called "offered traffic load". A measure
      of the amount of traffic being presented to be carried across a
      network compared to the capacity of the network to carry it.
   ...      
   Workload:  Also called "traffic workload". An evaluation of the
      amount of work that must be done in a network in order to
      facilitate the traffic demand. 
-->


6) <!-- [rfced] Please review the text starting with "from the entry..." and let
us know how it can be updated for clarity.

Original:
      In contrast, edge-to-edge is often used to describe the traffic
      flow from the entry to a domain or network, to the exit from that
      domain or network. 

Perhaps:
      In contrast, edge-to-edge is often used to describe the traffic
      flow from the entry of a domain or network to the exit of that
      domain or network.
-->


7) <!-- [rfced] May we update "a network described" to "a network like the one
described" to improve clarity?

Original:
   There are several problems associated with operating a network
   described in the previous section. 

Perhaps: 
   There are several problems associated with operating a network
   like the one described in the previous section. 
-->


8) <!-- [rfced] Would either 1) updating "How to" to "How do we" or 2) removing
the question marks improve readability of this text? Or do you prefer the current?

Original:
   A particular challenge is to formulate the problems that traffic
   engineering attempts to solve.  For example:

   *  How to identify the requirements on the solution space?

   *  How to specify the desirable features of solutions?

   *  How to actually solve the problems?

   *  How to measure and characterize the effectiveness of solutions?

Perhaps (update "How to" to "How do we"): 
   A particular challenge is to formulate the problems that traffic
   engineering attempts to solve.  For example:

   *  How do we identify the requirements on the solution space?

   *  How do we specify the desirable features of solutions?

   *  How do we actually solve the problems?

   *  How do we measure and characterize the effectiveness of solutions?

Or (remove question marks):
   A particular challenge is to formulate the problems that traffic
   engineering attempts to solve.  For example:

   *  How to identify the requirements on the solution space

   *  How to specify the desirable features of solutions

   *  How to actually solve the problems

   *  How to measure and characterize the effectiveness of solutions
-->


9) <!-- [rfced] Please review the comma after "automatically" here. Should the
comma be removed or replaced with "and"?

Original:
   *  automatically, online using constraint-based routing processes
      implemented on label switching routers

   *  automatically, offline using constraint-based routing entities
      implemented on external TE support systems.

Perhaps (removed comma): 
   *  automatically online using constraint-based routing processes
      implemented on Label Switching Routers (LSRs)

   *  automatically offline using constraint-based routing entities
      implemented on external TE support systems.

Or (replaced comma with "and"):
   *  automatically and online using constraint-based routing processes
      implemented on Label Switching Routers (LSRs)

   *  automatically and offline using constraint-based routing entities
      implemented on external TE support systems.
-->


10) <!-- [rfced] We note that [AFD03] uses the expansion "Approximate Fair
Dropping (AFD)", though the title of the reference is "Approximate
fairness through differential dropping". Please review and let us know if
any updates are needed for this expansion in this text.

Link to [AFD03]: https://dl.acm.org/doi/10.1145/956981.956985

Current:
   ... while others (such
   as Approximate Fairness Through Differential Dropping (AFD)
   [AFD03] have seen some implementation.
-->


11) <!-- [rfced] We added a semicolon and "in addition" to this sentence. We also
updated "area/Autonomous System (AS) size" to "the size of the area and
AS". Please review and let us know any objections.

Original
   ALB flooding can be resource intensive, since it requires link bandwidth
   to carry routing protocol link state advertisements, processor
   capacity to process those advertisements, and the overhead of the
   advertisements and their processing can limit area/Autonomous System
   (AS) size. 

Current:
   ALB flooding can be resource intensive, since it requires link bandwidth
   to carry routing protocol link state advertisements and processor
   capacity to process those advertisements; in addition, the overhead of the
   advertisements and their processing can limit the size of the area and AS. 
-->


12) <!-- [rfced] These sentences are quite similar and point back to each other
(i.e., the sentence in Section 4.1 points to Section 4.3.1 and vice
versa). Please review and let us know if any updates are needed here.

Current Section 4.1: 
   A fully functional TE system is likely to use all aspects of time-
   dependent, state-dependent, and event-dependent methodologies as
   described in Section 4.3.1.

Current Section 4.3.1:
   Lastly, note that a fully functional TE system is likely to use all
   aspects of time-dependent, state-dependent, and event-dependent
   methodologies as described in Section 4.1.
-->


13) <!-- [rfced] How may we clarify "such as [RFC8040]" here?

Original:
   However, SDN may also combine centralized control of
   resources, and facilitate application-to-network interaction via an
   application programming interface (API) such as [RFC8040]. 

Perhaps:
   However, SDN may also combine centralized control of
   resources and facilitate application-to-network interaction via an
   Application Programming Interface (API), such as the one described in [RFC8040]. 
-->


14) <!-- [rfced] How may we update the text starting with "underlying network
topology..." for clarity? Specifically, what items are being connected in
a series?

Original:
   Therefore, the SDN
   control plane needs to be aware of the underlying network topology,
   capabilities and current node and link resource state.

Perhaps:
   Therefore, the SDN
   control plane needs to be aware of the underlying network topology,
   capabilities, and current node and link resource state.
-->


15) <!-- [rfced] Please review the text starting with "performed using...". How
can we revise to make the items connected by "either...or" have parallel
structure?

Original:
   When a suitable path has been
   computed the programming of the explicit network path may be
   performed using either a signaling protocol that traverses the length
   of the path [RFC3209] or per-hop with each node being directly
   programmed [RFC8283] by the SDN controller.

Perhaps: 
   When a suitable path has been
   computed, the programming of the explicit network path may be
   either performed using a signaling protocol that traverses the length
   of the path [RFC3209] or performed per-hop with each node being directly
   programmed [RFC8283] by the SDN controller.
-->


16) <!-- [rfced] Please review the ratio notation in the parenthetical. Is the
current correct, or would "75% to 25%", "75%:25%", or something else be
better?

Original:
   Load-Balancing:  The traffic is distributed among the available
      access networks following a distribution ratio (e.g., 75% - 25%).
-->


17) <!-- [rfced] We do not see "MP-DCCP" in RFC 4340. We have updated this
sentence to use "DCCP". Please let us know any objections.

Current:
   Extensions to the Datagram Congestion Control Protocol (MP-DCCP)
   [RFC4340] to support multipath operations are defined in
   [MULTIPATH-DCCP].

Updated:
   Extensions to the Datagram Congestion Control Protocol (DCCP)
   [RFC4340] to support multipath operations are defined in
   [MULTIPATH-DCCP].
-->


18) <!-- [rfced] Will the use of both "in general" and "in particular" in this
text be difficult for the reader to follow? Please review and let us know
if this sentence should be updated for clarity.

Original:
   However, distributed applications in general and, in
   particular, bandwidth-greedy P2P applications that are used, for
   example, for file sharing, cannot directly use those techniques. 

Perhaps:
   However, in general, distributed applications
   (particularly, bandwidth-greedy P2P applications that are used for
   file sharing, for example) cannot directly use those techniques. 
-->


19) <!-- [rfced] Please review "service" (lowercased) and "Service" (capitalized)
in the parenthetical in this sentence. Should the capitalization be
consistent?

Original:
   The ALTO Protocol uses a REST-ful
   design and encodes its requests and responses using JSON [RFC8259]
   with a modular design by dividing ALTO information publication into
   multiple ALTO services (e.g., the Map service, the Map-Filtering
   Service, the Endpoint Property Service, and the Endpoint Cost
   Service).
-->


20) <!-- [rfced] Would it be helpful for readers to include a citation for
"original RSVP specification" here?

Original:
   One of the issues with the original RSVP specification was
   scalability.  
-->


21) <!-- [rfced] Please confirm that the pointer to Section 5.1.3.4 is correct. We
ask because Section 5.1.3.4 is titled "RSVP-TE". Should this be updated
to Section 5.1.3.3?

Current:
   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.4).
-->


22) <!-- [rfced] Would you like to update "TE Router ID" to "Traffic Engineering
router ID" to match the usage in RFC 5305 and in the "IS-IS Top-Level TLV
Codepoints" registry at
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints?

Original:
   *  IS-IS uses the Extended IS Reachability TLV (type 22), the
      Extended IP Reachability TLV (type 135), and the TE Router ID TLV
      (type 134).  
-->


23) <!-- [rfced] Please review the instances of "PCE" in this paregraph. Should
any of these be updated to either "a PCE" or "PCEs"?

Original:
   PCEs form key components of a number of TE systems.  More information
   about the applicability of PCE can be found in [RFC8051], while
   [RFC6805] describes the application of PCE to determining paths
   across multiple domains.  PCE also has potential use in Abstraction
   and Control of TE Networks (ACTN) (see Section 5.1.2.2), Centralized
   Network Control [RFC8283], and Software Defined Networking (SDN) (see
   Section 4.3.2).
-->


24) <!-- [rfced] FYI - We have updated this sentence as follows (i.e., hyphenation
with "XML- and JSON-encoded"). Please let us know any objections.

Original:
   These protocols use XML or JSON encoded messages.  

Perhaps: 
   These protocols use XML- or JSON-encoded messages.  
-->


25) <!-- [rfced] May we update this sentence in one of the following ways?

Original:
   The messages of PCEP are TLV-based, not
   defined by a data modeling language such as YANG.

Perhaps:
   The messages of PCEP are TLV based; they are not
   defined by a data-modeling language such as YANG.

Or:
   PCEP messages are TLV based; they are not
   defined by a data-modeling language such as YANG.
-->


26) <!-- [rfced] Will it be clear to readers where the "such as..." phrase ends?

Original:
      Derived statistics such as traffic matrices, link utilization,
      latency, packet loss, and other performance measures of interest
      which are determined from network measurements can be used as
      indicators of prevailing network conditions.  

Perhaps (after "measurements): 
      Derived statistics (such as traffic matrices, link utilization,
      latency, packet loss, and other performance measures of interest
      that are determined from network measurements) can be used as
      indicators of prevailing network conditions.

Or (after "interest"):
      Derived statistics (such as traffic matrices, link utilization,
      latency, packet loss, and other performance measures of interest)
      that are determined from network measurements can be used as
      indicators of prevailing network conditions.  
-->


27) <!-- [rfced] May we update the text after "destination node" as
follows to improve clarity?

Original:
   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 configured
   policies. 

Perhaps:
  An important aspect of the traffic mapping function is the ability to
  establish multiple paths between an originating node and a
  destination node and to distribute the traffic
  across those paths according to configured
  policies.
-->


28) <!-- [rfced] Please review "buffer management and packet scheduling
mechanisms" and clarify if A) "buffer management" refers to "mechanisms"
or B) "buffer management" is its own entity and separate from
"mechanisms".

Original:
   PHBs are
   delivered using buffer management and packet scheduling mechanisms
   and require that the ingress nodes use traffic classification,
   marking, policing, and shaping.

Perhaps A:
   PHBs are
   delivered using buffer-management and packet-scheduling mechanisms
   and require that the ingress nodes use traffic classification,
   marking, policing, and shaping.

Perhaps B:
   PHBs are
   delivered using buffer management and packet-scheduling mechanisms
   and require that the ingress nodes use traffic classification,
   marking, policing, and shaping.
-->


29) <!-- [rfced] May we update "routing protocols interactions" as follows for
clarity?

Original:
   ...but this approach is difficult to use and imprecise because
   of the way the routing protocols interactions occur across the
   network.

Perhaps: 
   ...but this approach is difficult to use and imprecise because
   of the way interactions among routing protocols occur across the
   network.
-->


30) <!-- [rfced] Please review "the one congested connections" here. Should this
be updated to "the one congested connection" (singular "connection") or
something else? This sentence appears in RFC 3272, but it doesn't seem
quite right.

Original:
   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. 

Perhaps: 
   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 connection.
-->


31) <!-- [rfced] The URL for this reference returns a "Page Not Found" error. We
updated as shown below. Please let us know any objections.

Original:
   [FT01]     Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
              a Changing World", n.d.,
              <http://www.research.att.com/~mthorup/PAPERS/papers.html>.

Current:
   [FT01]     Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
              a Changing World", IEEE Journal on Selected Areas in
              Communications, DOI 10.1109/JSAC.2002.1003042, May 2002,
              <https://ieeexplore.ieee.org/document/1003042>.
-->


32) <!-- [rfced] The following URL appears to be to a personal webpage. May we update to use
https://ieeexplore.ieee.org/document/397042 instead?

Original:
   [YARE95]   Yang, C. and A. Reddy, "A Taxonomy for Congestion Control
              Algorithms in Packet Switching Networks", Article IEEE
              Network Magazine, p. 34-45, 1995,
              <http://www.cs.uccs.edu/~zbo/teaching/CS522/Projects/
              Taxonomy_Network1995.pdf>.

Perhaps: 
   [YARE95]   Yang, C. and A. Reddy, "A Taxonomy for Congestion
              Control Algorithms in Packet Switching Networks", IEEE
              Network, Volume 9, Issue 4, Pages 34-45,
              DOI 10.1109/65.397042, August 1995,
              <https://ieeexplore.ieee.org/document/397042>.
-->


33) <!-- [rfced] Would it be helpful to align the format of Appendices A.1 and A.2
by including the word "Section" before section numbers in A.1? Also, may
we put the section titles in parentheses with quotation marks? Or do you prefer the current?

Original (A.1):
   1.0 Introduction:  Edited in place in Section 1.

      1.1 What is Internet Traffic Engineering?:  Edited in place in
         Section 1.1.

      1.2 Scope:  Moved to Section 1.3.

      1.3 Terminology:  Moved to Section 1.4 with some obsolete terms
         removed and a little editing.

Perhaps (title in parentheses with quotation marks):
   Section 1 ("Introduction"): Edited in place in Section 1.

      Section 1.1 ("What is Internet Traffic Engineering?"):  Edited 
         in place in Section 1.1.

      Section 1.2 ("Scope"):  Moved to Section 1.3.

      Section 1.3 ("Terminology"):  Moved to Section 1.4 with some 
      obsolete terms removed and a little editing.
-->


34) <!-- [rfced] The following text appears in the Acknowledgements
section. Should it appear in the Contributors section instead? The text
says, "the original authors should be considered as Contributors to this
work".

Original:
   Much of the text in this document is derived from RFC 3272.  The
   editor and contributors to this document would like to express their
   gratitude to all involved in that work.  Although the source text has
   been edited in the production of this document, the original authors
   should be considered as Contributors to this work.  They were:

      Daniel O. Awduche
      Movaz Networks

      Angela Chiu
      Celion Networks

      Anwar Elwalid
      Lucent Technologies

      Indra Widjaja
      Bell Labs, Lucent Technologies

      XiPeng Xiao
      Redback Networks
-->


35) <!-- [rfced] FYI - We added a citation and corresponding reference entry
for the errata report in this sentence.

Original:
   The production of this document includes a fix to the original text
   resulting from an Errata Report by Jean-Michel Grimaldi.
   
Perhaps: 
   The production of this document includes a fix to the original text
   resulting from an errata report #309 [Err309] by Jean-Michel
   Grimaldi.
-->


36) <!-- [rfced] Reference Relevance

a) Please review the use of "MPLS-TE [RFC3209]" in these sentences. We do not
see the exact term "MPLS-TE" in RFC 3209, though we do see "traffic
engineering with MPLS" and "traffic engineering over MPLS", both with a
reference to RFC 2702. Also, the title of RFC 3209 is "RSVP-TE: Extensions to
RSVP for LSP Tunnels". Please review and let know if any updates are needed.

Original:
   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]. 
   ...
   The concept of constraint-based routing within the context of MPLS TE
   requirements in IP networks was first described in [RFC2702] and led
   to developments such as MPLS-TE [RFC3209] as described in
   Section 5.1.3.3.      


b) We do note see the exact term "IP Performance metrics" in RFC 5664, though
we do see two instances of "performance". Please confirm this citation is
correct.

Current:
   *  Expansion of the function of IP Performance metrics [RFC5664]
      where specific constraint-based routing (flex-algo) can be
      instantiated within the network based on the results of
      performance measurement.


c) Please confirm that the [RFC7471] and [RFC5329] citations are correct. We 
do not see "Router Address" in RFC 7471, and we see "Router IPv6 Address" as 
the name of the TLV in RFC 5329. 

Original:
   *  OSPFv2 uses Opaque LSA type 10 [RFC5250], and OSPFv3 uses the
      Intra-Area-TE-LSA.  In both OSPF cases, two top-level TLVs are
      used (Router Address and Link TLVs), and these use sub-TLVs to
      carry the TE parameters (as defined in [RFC7471] for OSPFv2 and
      [RFC5329] for OSPFv3.
-->


37) <!-- [rfced] Abbreviations

a) We note that "traffic engineering" and "Segment Routing" and their 
abbreviations "TE" and "SR" are used often throughout the document. Would 
you like to expand the first instance and then use the abbreviation in the 
remainder of the document? Or do you prefer the current arrangement?

We did this for terms like "Label Switched Paths (LSP)", "Label Switching
Router (LSR)", "Autonomous System (AS)" and "Path Computation Element (PCE)"
that appeared only a few times in the document.


b) FYI - We have added expansions for abbreviations upon first use per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.

point-to-point (P2P)
Standards Development Organizations (SDOs)
Segment Identifier (SID)
Simple Two-way Active Measurement Protocol (STAMP)
Two-Way Active Measurement Protocol (TWAMP)
MPLS Adaptive Traffic Engineering (MATE)
-->


38) <!-- [rfced] Terminology

a) May we hyphenate "traffic engineering" in the attributive position (i.e., adjective 
before a noun)? Note that this may not apply if TE is used after the first expansion per
the question above.


b) Would you like to update "head-end" to "headend" (no hyphen)? Most instances
appear in Section 5.1.1.3; that section cites RFC 9256, which uses "headend".


c) We note inconsistencies in the terms below throughout the text. Should these
be uniform? If so, please let us know which form is preferred.

IETF network slice vs. IETF Network Slice
  Note: It looks like draft-ietf-teas-ietf-network-slices-25 mostly uses
  the capitalized form.

MPLS TE  vs. MPLS-TE


d) We note inconsistencies in the terms listed below. We chose the form on the
right. Please let us know any objections.

prefix SID vs. Prefix SID
end-point vs. endpoint
IP Performance metrics vs. IP Performance Metrics
SR policy vs. SR Policy
flexible algorithm vs. Flexible Algorithm (per RFC 9350)
time scale vs. timescale


e) FYI - We made the following hyphenation choices (note that some of these
vary from usage in RFC 3272 but are consistent with usage in more recent
RFCs):

end-user vs. end user (open as noun)
edge-node vs. edge node (open as noun)
best effort vs. best-effort (hyphen for adjective before noun)
equal cost vs. equal-cost (hyphen for adjective before noun) 
end-system vs. end system (open as noun)
link state vs. link-state (hyphen for adjective; open for noun)
mission critical vs. mission-critical (hyphen for adjective before noun)
traffic aggregate vs. traffic-aggregate (hyphen for adjective; open for noun)
traffic oriented > traffic-oriented (hyphen for adjective before noun)


f) This document contains four instances of "TE-tunnel" in Section 7. Although
"TE-tunnel" was used in RFC 3272 and a few other RFCs, "TE tunnel" (no hyphen)
is much more common in the RFC Series. Please review and let us know if any
updates are needed here.


g) FYI - The following terms appear in Section 5.1.3.2, which discusses RSVP
[RFC2205]. We updated the terms as follows to match usage in RFC 2205.

PATH message > Path message 
RESV message > Resv message 


h) We updated "Segment-List" to "segment list" as we we do not see
"Segment-List" in published RFCs. Please review.

Original:
   Each SR
   path consists of a Segment-List (an SR source-routed path), and the
   head-end uses the endpoint and color parameters to classify packets
   to match the SR policy and so determine along which path to forward
   them. 


i) The term "class-list" (with hyphen) is used consistently in Section
6.8. Should this be updated to "class type" (no hyphen) or "Class-Type"
(initial caps with hyphen)? We see that the latter is used in RFC 4124, 
which is cited in Section 6.8.


j) The term "flex-algo" is used in this document with a reference to RFC 9350,
but "flex-algo" does not appear in RFC 9350. In fact, we only see this term
used once in the RFC Series (RFC 9433). Would you like to update instances of
"flex-algo" to either "Flexible Algorithm" or "Flex-Algorithm", both of which
appear in RFC 9350? Or would you like to leave this as is?


k) FYI - We updated "Edge computing" and "Datacenter interconnect" as follows
to match usage in past RFCs.

Current:
   The ALTO Working Group is
   evaluating the use of network TE properties while making application
   decisions for new use cases such as Edge computing and Datacenter
   interconnect.

Perhaps:
   The ALTO Working Group is
   evaluating the use of network TE properties while making application
   decisions for new use cases such as edge computing and data-center
   interconnect.


l) Please review the following terms and verify if the quotation marks are
necessary.

"acceptable service quality"
"clouds"
"effective capacity"
"five-tuple"
"intent"
"underlay"
"overlay"
"policy"
"publication/subscription" techniques 
"shortest paths"
"sliced"


m) We see a number of uses of the "/" character separating terms in this
document. Please review and let us know if these are okay or if we
should change any instances to "and/or", "and", or "or".

Some examples:

avoiding/relieving
BGP/Service route
control/controller level
data/forwarding plane
protected/restored
protection/restoration
SIDs/Labels
sources/destinations
-->


39) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

a) For example, please consider whether "natively" should be updated.

Current:
   Note that
   QUIC [RFC9000] natively supports the switching and steering
   functions. 


b) In addition, please consider whether "tradition" should be updated for
clarity.  While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.

Current:
   The traditional approach to routing in an IGP network relies on the
   IGPs deriving "shortest paths" over the network based solely on the
   IGP metric assigned to the links. 
   ...
   RED provides congestion
   avoidance that is better than or equivalent to traditional
   Tail-Drop (TD) queue management (drop arriving packets only
   when the queue is full). 
-->


Thank you.

RFC Editor/st/rv



On Jan 10, 2024, at 11:26 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/01/10

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9522.xml
  https://www.rfc-editor.org/authors/rfc9522.html
  https://www.rfc-editor.org/authors/rfc9522.pdf
  https://www.rfc-editor.org/authors/rfc9522.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9522-diff.html
  https://www.rfc-editor.org/authors/rfc9522-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9522-xmldiff1.html

Alt-diff of the text (allows you to more easily view changes 
where text has been deleted or moved): 
  https://www.rfc-editor.org/authors/rfc9522-alt-diff.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9522

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9522 (draft-ietf-teas-rfc3272bis-27)

Title            : Overview and Principles of Internet Traffic Engineering
Author(s)        : A. Farrel, Ed.
WG Chair(s)      : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou Berger

Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston