Subject: [lisp] Request for private LCAF allocation

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 27 Mar 2017 20:53:04 +0200

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].

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.

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.

Thanks,
Alberto

[1] https://tools.ietf.org/html/rfc1918

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Mar 2017 11:59:48 -0700

> 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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 27 Mar 2017 14:48:00 -0500

On Mon, Mar 27, 2017 at 1:59 PM, Dino Farinacci <[email-masked]> 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
> 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

Again, that is deployment-specific and should not be specified by the IETF.

Alberto

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Mar 2017 19:01:57 -0400

That does not sound quite right.
If the problem is experimentation, then what you describe (reserving one 
code point, if you need several structure your use in such a way to give 
you the spac eyou need) makes good sense.

If the problem is private use LCAF types being deployed in production, 
then we need some way to avoid collisions from competing private uses. 
There are several ways to address this, but ignoring it is not a good idea.

Yours,
Joel

On 3/27/17 2:53 PM, Alberto Rodriguez-Natal wrote:
> 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.
>
> 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.
>
> Thanks,
> Alberto
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>