Alvaro, For these two:
>> 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 >In this case, do you think we should allow all AFIs as well? For this one accepting MACs for example seems a bit odd. Even DNs. The usage of this LCAF seems very oriented to defining a route. If we could find an easy way to describe v4, v6 and only those LCAFs that can complement v4 and v6 hops. Not sure how to be precise here. >> 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. > I don't see a problem extending to L2 -- that seems to be enough, right? Yes, I would say, extending to L2 only would be enough in this case Thanks! Marc From: Alvaro Retana <[email protected]> Date: Wednesday, May 20, 2026 at 5:59 AM To: Marc Portoles Comeras (mportole) <[email protected]>; [email protected] <[email protected]> Subject: Re: [lisp] Re: I-D Action: draft-ietf-lisp-rfc8060bis-04.txt On May 19, 2026 at 2:58:29 PM, Marc Portoles Comeras wrote: Marc: 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? No concerns from me. The AFIs are defined in Table 1/§3, and they include L2 MACs and DNs, so that would work. > 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 In this case, do you think we should allow all AFIs as well? > 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. I don't see a problem extending to L2 -- that seems to be enough, right? > 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. 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. 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? I'll wait for others to comment before proposing a diff. Thanks! Alvaro.
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
