Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)

[Alberto Rodriguez-Natal <[e-mail]>]

Hi,

On 10 September 2013 21:43, Sander Steffann <[e-mail]> wrote:

> Hi,
>
> > Speaking personally, I have some concerns about this.
> >
> > I think my concerns can be lumped into two related categories.  Bother
> are about interoperability.
> >
> > Firstly, I find the registration of LCAFs without any explanation of how
> or why they would be used to be awkward.
>
> I have implemented some Python code that tries to use LCAFs, and I can
> only say that it is very difficult as an implementer to deal with LCAFs.
> Often I have no idea where I can expect which LCAF type. The RFCs don't
> give enough guidance here in my opinion.
>
> The specs allow way too much. As an implementer I don't want to be
> surprised because some other implementation suddenly decides to use LCAF
> type 3 to add the ASN to the address. Not to mention that an LCAF address
> can contain another LCAF address. So should all implementations now support
> type-2 LCAF address within type-3 LCAF addresses in case some
> implementation decides to add both an instance-id and an ASN? And will that
> be encoded as type-2 in type-3 or as type-3 in type-2? What about when
> someone decides to add type-5 Geo information to the mix? Should all
> implementations support all possible combinations?
>
> This will make it much too hard to write a good implementation.
>

First, I must say that I strongly share with this view regarding
implementation. I have faced the very same concerns while dealing with
LCAFs on the code, specially with nested LCAFs.


Regarding the JSON LCAF, I think we all agree that a LCAF format must have
a companion document describing its usage. However I believe this does not
apply (at least directly) to the JSON format. The idea of this format is to
be not constrained by any specification to allow total freedom on its
usage.

It has been said that this format will be mostly used for experimentation
or in intra-domain deployments. Since in these cases there is no
interoperation between entities beyond the ones involved in the experiment
or the domain, there is no need for a standard. These entities will agree
on how to use the format.  What should be provided by LISP
manufacturers/implementors is an interface to program the LISP device to
use and understand the concrete JSON LCAF usage. I think this interface is
out of scope of LISP WG.

In any case, if the WG feels that there is a need to standardize the JSON
LCAF usage, I believe this should be done per use-case. Either a document
covering different use-cases in just one place (as the LCAF document does
with LCAF formats) or different documents covering different use-cases.

Alberto