Thanks Alvaro and Alberto, Yes, this sounds like a compelling reason to reserve an extra bit for the “no encapsulation”
If you guys include it in the next version of the rfc8060bis, we’ll do the same with the delegated mappings proposal, so that the two are aligned. Marc From: Alberto Rodriguez-Natal (natal) <[email protected]> Date: Friday, May 22, 2026 at 4:40 AM To: Alvaro Retana <[email protected]>; Marc Portoles Comeras (mportole) <[email protected]>; [email protected] <[email protected]> Subject: Re: [lisp] Re: I-D Action: draft-ietf-lisp-rfc8060bis-04.txt Hi folks, Please see two comments below on the last point. Alberto > 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. From draft-portoles-lisp-delegated-mappings: "When no encapsulation is needed Type 16 is also used but with all encapsulation bits set to 0." That value (0) works for me. In rfc8068bis, we need to clarify that the defined bits (UGNv...) are part of the Encapsulations field, and create a registry. [AR] Given that we have enough bits, my personal preference would be to reserve a bit to signal “No Encapsulation”. See also answer below. Question: the definitions of the bits say that they "can accept...encapsulation", which sounds to me like multiple encapsulations can be indicated. Is that ok, or should we enforce only one bit set at a time? [AR] I think we should allow to signal multiple possible encapsulations, thus multiple bits might be set at a time. This is a reason to reserve a bit for “No Encapsulation”.
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
