On Mon, Mar 27, 2017 at 1:59 PM, Dino Farinacci <[email protected]> wrote:
> > 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. > Certainly, that's the reason that motivated the JSON LCAF back in the day. The motivation for a private LCAF type is to avoid to be constrained to JSON and to give vendors/operators full freedom on how they use a private LCAF. > > > 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 point is that the usage of the private LCAF should be undefined. Different deployments may use it in different ways. Is up to the vendors/operators to implement a mapping system that works properly with private LCAFs on the role they use it. > > > 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's the point, that by default should be no interoperabilty between domains. Let's say that both Pepsi and Coke have deployments that use private LCAFs, each for its own purposes. They should not be capable of understanding each other LCAFs unless they explicitly coordinate offline to do so. Similarly to RFC 1918, private LCAFs should only be used within a domain and not cross domains unless those domains explicitly coordinate on that. If interoperability is needed across domains, probably a private LCAF is not the way to go. If your question is regarding interoperability across different devices within a single domain, then is up to that domain to make sure that the devices are able to interoperate if needed. > > 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? > Not sure if I follow. It is up for the implementation/deployment to decide if it allows to do so and how that would work. > > Would a private LCAF space be limited to an instance-ID and only run > within a VPN? > Again, that is deployment-specific and should not be specified by the IETF. Alberto > > Dino > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
