From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: lisp@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF
is undergoing rechartering. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
(iesg@ietf.org) by 2023-12-21.
Locator/ID Separation Protocol (lisp)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Padma Pillay-Esnault <padma.ietf@gmail.com>
Luigi Iannone <ggx@gigix.net>
Secretaries:
Alberto Rodriguez-Natal <natal@cisco.com>
Assigned Area Director:
Jim Guichard <james.n.guichard@futurewei.com>
Routing Area Directors:
John Scudder <jgs@juniper.net>
Jim Guichard <james.n.guichard@futurewei.com>
Andrew Alston <andrew-ietf@liquid.tech>
Mailing list:
Address: lisp@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/lisp
Archive: https://mailarchive.ietf.org/arch/browse/lisp/
Group page: https://datatracker.ietf.org/group/lisp/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/
LISP supports an overlay routing architecture that decouples the routing
locators and endpoint identifiers, thus allowing for efficient aggregation of
the routing locator space and providing persistent identifiers in the
endpoint space. LISP requires no changes to endpoints or routers that do not
directly participate in the LISP deployment. LISP aims for an incrementally
deployable protocol, so new features and services can be added easily and
quickly to the network using overlays. The LISP WG is chartered to continue
work on the LISP protocol, including minor extensions for which the working
group has consensus on deeming them necessary for the use cases identified by
the working as main LISP applications. Such use cases have to be documented
in an applicability document providing rationale for the work done.
The working group will work on the following items:
- Moving to Standard Track: The core specifications of LISP have been
published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue
the work of moving select specifications to “Standard Track” (e.g., LISP
Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc).
- Map Server Reliable Transport: LISP control plane messages are transported
over UDP, however, in some cases, the use of a reliable transport protocol is
a better fit, since it actually helps reduce periodic signaling.
- YANG Models: The management of LISP protocol and deployments include data
models, OAM, as well as allowing for programmable management interfaces.
- LISP for Traffic Engineering: Specifics on how to do traffic engineering on
LISP deployments could be useful. For instance, encode in a mapping not only
the routing locators associated to EIDs, but also an ordered set of
re-encapsulating tunnel routers (RTRs) used to specify a path.
- NAT-Traversal: Support for a NAT-traversal solution in deployments where
LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
- Privacy and Security: The WG will work on EID anonymity, VPN segmentation
leveraging on the Instance ID, and traffic anonymization. The reuse of
existing mechanisms will be prioritized.
- LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be
used to connect LISP sites with non-LISP sites. However, LISP deployments
could benefit from more advanced internet-working, for instance by defining
mechanisms to discover such external connectivity.
- Mobility: Some LISP deployment scenarios include endpoints that move across
different LISP xTRs and/or LISP xTRs that are themselves mobile. Support
needs to be provided to achieve seamless connectivity.
- LISP Applicability: LISP has proved to be a very flexible protocol that can
be used in various use cases not considered during its design phase.
[RFC7215], while remaining a good source of information, covers one single
use case, which is no longer the main LISP application scenario. The LISP WG
will document LISP deployments for the most recent and relevant use cases, so
as to update and complement [RFC7215] as needed.
Milestones:
Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration
(Extension) [EXPERIMENTAL]
Mar 2024 - Submit LISP Reliable Transport document to the IESG for
consideration (Map Server Reliable Transport) [STANDARDS TRACK]
Mar 2024 - Submit LISP YANG model document to the IESG for consideration
(YANG Models) [EXPERIMENTAL]
Mar 2024 - Submit LISP Traffic Engineering document to the IESG for
consideration (Extension) [EXPERIMENTAL]
Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for
consideration (Mobility) [EXPERIMENTAL]
Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration
(NAT Traversal) [STANDARDS TRACK]
Nov 2024 - Submit LISP DDT bis document to the IESG for consideration
[STANDARDS TRACK]
Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration
[STANDARDS TRACK]
Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG for
consideration (Privacy and Security) [EXPERIMENTAL]
Mar 2025 - Submit LISP External Connectivity document(s) to the IESG for
consideration (LISP External Connectivity) [EXPERIMENTAL]
Jul 2025 - Submit LISP Mobility document(s) to the IESG for consideration
(Mobility) [EXPERIMENTAL]
Nov 2025 - Submit LISP Multicast document(s) to the IESG for consideration
[STANDARDS TRACK]
Mar 2026 - Submit LISP Applicability document(s) to the IESG for
consideration (LISP Applicability) [INFORMATIONAL]
Nov 2026 - Wrap-Up or recharter
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
lisp-chairs@ietf.org,
lisp@ietf.org
Subject: WG Action: Rechartered Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF
has been rechartered. For additional information, please contact the Area
Directors or the WG Chairs.
Locator/ID Separation Protocol (lisp)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Padma Pillay-Esnault <padma.ietf@gmail.com>
Luigi Iannone <ggx@gigix.net>
Secretaries:
Alberto Rodriguez-Natal <natal@cisco.com>
Assigned Area Director:
Jim Guichard <james.n.guichard@futurewei.com>
Routing Area Directors:
John Scudder <jgs@juniper.net>
Jim Guichard <james.n.guichard@futurewei.com>
Andrew Alston <andrew-ietf@liquid.tech>
Mailing list:
Address: lisp@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/lisp
Archive: https://mailarchive.ietf.org/arch/browse/lisp/
Group page: https://datatracker.ietf.org/group/lisp/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/
LISP supports an overlay routing architecture that decouples the routing
locators and endpoint identifiers, thus allowing for efficient aggregation of
the routing locator space and providing persistent identifiers in the
endpoint space. LISP requires no changes to endpoints or routers that do not
directly participate in the LISP deployment. LISP aims for an incrementally
deployable protocol, so new features and services can be added easily and
quickly to the network using overlays. The LISP WG is chartered to continue
work on the LISP protocol, including minor extensions for which the working
group has consensus on deeming them necessary for the use cases identified by
the working group as main LISP applications. Such use cases have to be
documented in an applicability document providing rationale for the work done.
The working group will work on the following items:
- Moving to Standard Track: The core specifications of LISP have been
published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue
the work of moving select specifications to “Standard Track” (e.g., LISP
Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc).
- Map Server Reliable Transport: LISP control plane messages are transported
over UDP, however, in some cases, the use of a reliable transport protocol
(such as TCP) is a better fit, since it actually helps reduce periodic
signaling.
- YANG Models: The management of LISP protocol and deployments including data
models, OAM, as well as allowing for programmable management interfaces.
- LISP for Traffic Engineering: Specifics on how to do traffic engineering on
LISP deployments could be useful. For instance, encode in a mapping not only
the routing locators associated to EIDs, but also an ordered set of
re-encapsulating tunnel routers (RTRs) used to specify a path.
- NAT-Traversal: LISP protocol extensions to support a NAT-traversal solution
in deployments where LISP tunnel endpoints are separated from by a NAT (e.g.,
LISP mobile node). The LISP WG will collaborate with the TSVWG working on
NAT-Traversal.
- Privacy and Security: The WG will work on EID anonymity, VPN segmentation
leveraging the Instance ID, and traffic anonymization. The reuse of existing
mechanisms will be prioritized.
- LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be
used to connect LISP sites with non-LISP sites. However, LISP deployments
could benefit from more advanced interworking, for instance by defining
mechanisms to discover such external connectivity.
- Mobility: Some LISP deployment scenarios include endpoints that move across
different LISP xTRs and/or LISP xTRs that are themselves mobile. Support
needs to be provided to achieve seamless connectivity.
- LISP Applicability: LISP has proved to be a very flexible protocol that can
be used in various use cases not considered during its design phase.
[RFC7215], while remaining a good source of information, covers one single
use case, which is no longer the main LISP application scenario. The LISP WG
will document LISP deployments for the most recent and relevant use cases, so
as to update and complement [RFC7215] as needed.
Milestones:
Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration
(Extension) [EXPERIMENTAL]
Mar 2024 - Submit LISP Reliable Transport document to the IESG for
consideration (Map Server Reliable Transport) [STANDARDS TRACK]
Mar 2024 - Submit LISP YANG model document to the IESG for consideration
(YANG Models) [EXPERIMENTAL]
Mar 2024 - Submit LISP Traffic Engineering document to the IESG for
consideration (Extension) [EXPERIMENTAL]
Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for
consideration (Mobility) [EXPERIMENTAL]
Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration
(NAT Traversal) [STANDARDS TRACK]
Nov 2024 - Submit LISP DDT bis document to the IESG for consideration
[STANDARDS TRACK]
Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration
[STANDARDS TRACK]
Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG for
consideration (Privacy and Security) [EXPERIMENTAL]
Mar 2025 - Submit LISP External Connectivity document(s) to the IESG for
consideration (LISP External Connectivity) [EXPERIMENTAL]
Jul 2025 - Submit LISP Mobility document(s) to the IESG for consideration
(Mobility) [EXPERIMENTAL]
Nov 2025 - Submit LISP Multicast document(s) to the IESG for consideration
[STANDARDS TRACK]
Mar 2026 - Submit LISP Applicability document(s) to the IESG for
consideration (LISP Applicability) [INFORMATIONAL]
Nov 2026 - Wrap-Up or recharter
Ballot announcement
Ballot Announcement
As discussed, the LISP WG has completed their initial set of RFCs and they are requesting to recharter with the main aim to develop a standards track solution. In addition, they will continue to work on previous items and some new items.