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

[Sander Steffann <[e-mail]>]

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.

Looking at the actual text there is something else that concerns me. LCAF type-1 (AFI List Type) is defined in a very confusing way. It is described in multiple use cases with different semantics, but I see no way for the receiver to know what is actually meant. Section 4.13.5. "Compatibility Mode Use Case" also confuses me:

"A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators."

How does the sender know what the receiver will support?

And then there seems to be a contradiction:

"The list of AFIs in an AFI List LCAF Type has no semantic ordering [...]"
"[...] where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address."

So the ordering does seem to be important after all...

Is it the intention to make this the default behaviour? That all such extra information should be encoded in a list with an AFI 0 address in the i.e. Geo LCAF address and the IP address that should be used in a AFI 1 or 2 address that follows next? Is this also meant to be supported in multiple layers, for example by sending a list with first a Geo LCAF, then an ASN LCAF and then a plain address? In that case it might be better to remove the addresses from all the 'annotation' types completely and define them to always be used in a list. Then the sender could always send it like that, and the receiver could skip over all annotations that it doesn't understand until it finds a non-LCAF AFI address.

I understand that the authors want to define a very flexible address format, but without any rules or guidelines on how to encode address and in which circumstances it will be too hard for implementors to implement correctly in an interoperable way. There are now too many different ways to encode the same information, and that must be fixed. Either by changing the format (which I would strongly prefer) or by giving strict guidelines on how the current flexibility is to be used.

Cheers,
Sander