Nice! Thanks for listening.
Adrian From: Padma Pillay-Esnault <padma.i...@gmail.com> Sent: 08 July 2025 15:24 To: adr...@olddog.co.uk Cc: last-c...@ietf.org; draft-ietf-lisp...@ietf.org; lisp-cha...@ietf.org; lisp@ietf.org; Dino Farinacci <farina...@gmail.com> Subject: Re: [Last-Call] Re: [lisp] Re: Last Call: <draft-ietf-lisp-te-21.txt> (LISP Traffic Engineering) to Experimental RFC 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 <mailto: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 <mailto:padma.i...@gmail.com> > Sent: 08 July 2025 01:22 To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org> ; draft-ietf-lisp...@ietf.org <mailto:draft-ietf-lisp...@ietf.org> ; lisp-cha...@ietf.org <mailto:lisp-cha...@ietf.org> ; lisp@ietf.org <mailto:lisp@ietf.org> ; Padma Pillay-Esnault <padma.i...@gmail.com <mailto:padma.i...@gmail.com> >; Dino Farinacci <farina...@gmail.com <mailto: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 <mailto: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 <mailto:iesg-secret...@ietf.org> <iesg-secret...@ietf.org <mailto:iesg-secret...@ietf.org> > Sent: 14 May 2025 15:54 To: IETF-Announce <ietf-annou...@ietf.org <mailto:ietf-annou...@ietf.org> > Cc: draft-ietf-lisp...@ietf.org <mailto:draft-ietf-lisp...@ietf.org> ; james.n.guich...@futurewei.com <mailto:james.n.guich...@futurewei.com> ; lisp-cha...@ietf.org <mailto:lisp-cha...@ietf.org> ; lisp@ietf.org <mailto: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 <mailto:last-c...@ietf.org> mailing lists by 2025-05-28. Exceptionally, comments may be sent to i...@ietf.org <mailto: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 <mailto:ietf-annou...@ietf.org> To unsubscribe send an email to ietf-announce-le...@ietf.org <mailto:ietf-announce-le...@ietf.org> _______________________________________________ lisp mailing list -- lisp@ietf.org <mailto:lisp@ietf.org> To unsubscribe send an email to lisp-le...@ietf.org <mailto:lisp-le...@ietf.org>
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
