Hi Adrian Thank you for your review and suggestions.
How about if we add the following in the introduction to address your comment? Introduction This document describes extensions to the Locator/Identifier Separation Protocol (LISP) for traffic engineering features. -New begin- For clarity, this document adopts the definition of Traffic Engineering provided in [RFC9522]. Specifically, TE in the Internet context is defined as comprising three main components: Policy: The specification of operator intent with respect to traffic handling, such as performance objectives or path constraints. Path Steering: The ability to influence or determine the actual forwarding paths used by traffic, consistent with the policy. Resource Management: The monitoring and allocation of network resources to support the desired traffic behavior. This document primarily focuses on the Path Steering aspect of TE, by specifying how Explicit Locator Paths (ELPs) can be used to guide traffic through specific intermediate xTRs in a LISP network. Elements of Policy may be implicitly supported where operator intent is reflected in ELP selection, and Resource Management is assumed to be handled by external control systems or network management tools. A detailed discussion of those aspects is out of scope for this document. - New end - Thanks Padma (on behalf on all the co-authors) On Wed, May 14, 2025 at 10:35 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > Hi all, > > The words "Traffic Engineering" caused the claxon to go off in my cave > deep below the citadel. > > You may find it helpful to your readers to give some explanation of TE. > Although this is commonly assumed to be a well-understood term, it isn't > always interpreted in the same way. > A reference you could use is RFC 9522. This defines TE in the Internet > context and splits it into Policy, Path Steering, and Resource Management. > It may be a good idea for this draft to explain which of those components > it addresses (possibly all of them). > > Cheers, > Adrian > > -----Original Message----- > From: iesg-secret...@ietf.org <iesg-secret...@ietf.org> > Sent: 14 May 2025 15:54 > To: IETF-Announce <ietf-annou...@ietf.org> > Cc: draft-ietf-lisp...@ietf.org; james.n.guich...@futurewei.com; > lisp-cha...@ietf.org; lisp@ietf.org > Subject: Last Call: <draft-ietf-lisp-te-21.txt> (LISP Traffic Engineering) > to Experimental RFC > > > The IESG has received a request from the Locator/ID Separation Protocol WG > (lisp) to consider the following document: - 'LISP Traffic Engineering' > <draft-ietf-lisp-te-21.txt> as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2025-05-28. Exceptionally, comments > may > be sent to i...@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document describes how LISP re-encapsulating tunnels can be used > for Traffic Engineering purposes. The mechanisms described in this > document require no LISP protocol changes but do introduce a new > locator (RLOC) encoding. The Traffic Engineering features provided > by these LISP mechanisms can span intra-domain, inter-domain, or a > combination of both. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lisp-te/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list -- ietf-annou...@ietf.org > To unsubscribe send an email to ietf-announce-le...@ietf.org > > _______________________________________________ > lisp mailing list -- lisp@ietf.org > To unsubscribe send an email to lisp-le...@ietf.org >
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
