> Hi all, > > Based in deployment experience we have seen a need for private ad-hoc and > use-case-specific LCAF types. However, current LCAF space does not account > for a private use similar to the private IP space defined in [1].
I have seen the need to use private space as well and by using the JSON LCAF Type as an RLOC-record, I find it very convienent and flexible to define my own parameters and extend to add more easily. > Due to the limited LCAF space, rather than reserving a subset of types for > private use as in [1] we propose to reserve only one number (e.g. LCAF type > 254). If needed, private deployments can define private subtypes encoded > within that private LCAF type. The encoding of the private LCAF (besides the > common LCAF header) is not specified and would be deployment-specific. Could you be more specific if you would use this LCAF type for EID-records as well as RLOC-records? If the latter, it is easier to deploy since what is returned to a caller assumes the caller knows what it wants to lookup. But for EID-records, any new format that is not standard will be hard for the mapping system to support (right now LISP-ALT and LISP-DDT). So we would need some discussion about this. > The purpose of requesting a LCAF type to be allocated as private, instead of > just using one of the currently unallocated types, is to avoid collisions > with future LCAF types that may appear. We would like to ask the WG for > feedback on this and to trigger the process to request a new LCAF type to be > allocated by IANA. Sure, this makes sense to have a reserved one. But having a reserved LCAF is only the first step. How about interoperability? That is, can a general mapping system have both public LCAFs and private LCAFs and interoperate when an xTR that doesn’t support the private space can talk to an xTR that does as well as two old xTRs that use the same mapping system which supports both? Would a private LCAF space be limited to an instance-ID and only run within a VPN? Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
