Hi Adrian Agree to your suggestion will shorten it to
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 (TE) provided in [RFC9522]. Specifically, TE in the Internet context is defined as comprising three main components: policy, path steering, and resource management. 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 Tunnel Routers (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 again for your review Padma (and on behalf of co-authors) On Tue, Jul 8, 2025 at 2:19 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > Hi Padma, > > > > That text looks good. I’m not sure it is necessary to repeat the > definitions of the three component terms (just listing them would be OK). > But it also doesn’t hurt to include them. > > > > Cheers, > > Adrian > > > > *From:* Padma Pillay-Esnault <padma.i...@gmail.com> > *Sent:* 08 July 2025 01:22 > *To:* adr...@olddog.co.uk > *Cc:* last-c...@ietf.org; draft-ietf-lisp...@ietf.org; > lisp-cha...@ietf.org; lisp@ietf.org; Padma Pillay-Esnault < > padma.i...@gmail.com>; Dino Farinacci <farina...@gmail.com> > *Subject:* [Last-Call] Re: [lisp] Re: Last Call: > <draft-ietf-lisp-te-21.txt> (LISP Traffic Engineering) to Experimental RFC > > > > 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
