Hi, While reviewing the text we’ve detected some conflicts in the AFI values that are allowed for some of the LCAF types and the ideas proposed in related RFCs and lisp drafts.
Could the authors give an additional pass to these sections for consistency? The ones that we’ve found in particular: 4.2 The Instance ID LCAF Type The text claims <<Only AFI values for the Unspecified Encoded Address (0), IPv4 (1), and IPv6 (2) are valid in this LCAF Type. Any other AFI value is invalid and the LCAF Type MUST be silently ignored.>> However, for segmentation, the eid mobility draft (https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/) proposes the use of the IID LCAF with MACs and also uses a well-known DN string to support multihoming. Additionally, in RFC 9735 we decided to enforce the use of segmentation when distributing DNs, and this would conflict with the restriction. Generalizing, when encoding EIDs we may want to use segmentation to isolate vendor specific use cases, or new proposals like the one in https://datatracker.ietf.org/doc/draft-wang-lisp-ai-agent/ Any concerns in generalizing the text to accept all the AFIs in section 4.1? If LCAF nesting is a concern, we could try to set a limit there or maybe enforce the use of LCAF lists when encoding segmented LCAFs. 4.9 The Explicit Locator Path LCAF Type Similar concern with restricting AFI values to v4 and v6 in this LCAF. As an example, the delegated mappings case proposes augmenting locator information by encoding supported data-planes by using LCAF type 16 + the v4, v6 locator. https://www.ietf.org/archive/id/draft-portoles-lisp-delegated-mappings-00.html 4.8. The Multicast Info LCAF Type This one also restricts to v4 and v6, while the mobility draft (https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/) attempts to extend its use to register l2 broadcast groups. could we add MACs to the accepted ones? We can cite eid mobility draft as an additional example. Besides AFI consistency, a request for the authors in this LCAF type: 4.15. The Encapsulation Format LCAF Type Could you propose a value for “no encapsulation” (or native forwarding) in the list of encapsulation options? Since following RFC9301 any v4 or v6 RLOC implicitly means LISP encap (RFC9300), we miss a way to explicitly indicate that a certain RLOC can be used as a “non-encap” next-hop. https://www.ietf.org/archive/id/draft-portoles-lisp-delegated-mappings-00.html gives an example of when this may be used. Thanks, Marc From: Alvaro Retana <[email protected]> Date: Tuesday, February 17, 2026 at 9:33 AM To: [email protected] <[email protected]> Subject: [lisp] Re: I-D Action: draft-ietf-lisp-rfc8060bis-04.txt Hi! This version merges rfc9306 (Vendor-Specific LCAF) in. Please let us know if you have any comments or questions. Thanks! Alvaro. On February 17, 2026 at 12:19:48 PM, [email protected] ([email protected]<mailto:[email protected]>) wrote: Internet-Draft draft-ietf-lisp-rfc8060bis-04.txt is now available. It is a work item of the Locator/ID Separation Protocol (LISP) WG of the IETF. Title: LISP Canonical Address Format (LCAF) Authors: Alvaro Retana Dino Farinacci Job Snijders Alberto Rodriguez-Natal Name: draft-ietf-lisp-rfc8060bis-04.txt Pages: 34 Dates: 2026-02-17 Abstract: This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060 and RFC 9306. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc8060bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-lisp-rfc8060bis-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-rfc8060bis-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
