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

[Dino Farinacci <[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.

I have implemented a slew of LCAFs as well. But with any general design, it is usually hard to nail down specific combination use-cases. So rather than try to build the LCAF implementation directly from the LCAF spec, you should first keep in mind and design what use-case you want to solve. Then you decide what LCAF is needed for EID encoding and RLOC encoding.

This is precisely the reason we have will continue to need companion documents.

I have found in my implementation experience, that doing LCAF encoding was not that bad. That is because I had precisely in mind what I wanted to do. Here are some examples:

(1) I wanted to support VPNs, so I had to do was support the Instance-ID LCAF for EID encoding only.

(2) I wanted to know physically where RLOCs (ETRs, RTRs, or PETRs) resided so I wanted to have a 2-tuple RLOC encoding of RLOC address and Geo-Coordinates. So I implemented the Geo-Coordinate LCAF for RLOC encoding only.

> 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

There will be other configuration and product details that will dictate what you think you need to support versus having a general implementation that will get very complex.

The LCAF spec says what one COULD do, not that you should do it or it is the last word on the examples given within.

> 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? 

We did this at cisco because one OS wanted to prototype something and still interoperate with the other OS. So it was useful to do the recursion in the AFI-List LCAF. But we did one level and kept it simple.

> This will make it much too hard to write a good implementation.

A good implementation is not one that tries to do everything.

But this discussion is begging the question, "it would be nice to know what LCAFs I can return to a requesting system". And hence I would like to propose a Capabilities Type LCAF. I will send another email detailing what I'm suggesting.

And even more importantly, one needs to ask what the mapping system supports in terms of the various combinations of LCAF encoding for an EID, or I should call it, as the DDT spec calls it, a "extended-EID". However, the RLOC format of any combination of LCAFs is less important to the mapping system because it is just the output of the lookup which either an ETR is doing or a map-server is doing as part of proxy-replying. But the structure of the DDT with respect to multi-tuple nature an LCAF encoded EID address can be is crucial to figure out.

We do have some experience on the LISP pilot network with 2-tuple EIDs where <iid><ipv4-eid> and <iid><ipv6-eid> type extended EIDs are deployed (where <iid> is an instance-id).

> 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:

Right, because it is a package. And how you interpret it depends on the feature that uses such a package.

> "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?

If it is in the mapping system, the receiver (ETR, RTR, PETR, SDN controller) registered it. The question is does the encapsulator know how to use the information.

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

The ordering does not matter. You can put the Geo-Coordinate entry before the AFI encoded RLOC address or afterwards and an implementation that can parse an AFI-List Type should be able to get what it wants wherever it is located.

> Is it the intention to make this the default behaviour? That all such extra information should be encoded in a

No, that is not the intention. You have to look at each use-case. One can merely program Geo-Coordinates as RLOC entries with no RLOC address creating a control-plane only function using the mapping database. So again, it depends what one is trying to accomplish.

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

You use the AFI-List Type when you have a multi-tuple RLOC encoding that contains multiple LCAFs. But if you have one LCAF you want to use, each have AFI encoded RLOC addresses that accompany them. That is, the more popular case.

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

We need companion documents. And I believe the working group will embrace the concept once the critical work is complete. Right now we are at a timing rock and hard place where the working group process cannot support accepting more work. I wish the process could be more parallel but the chairs want to meet the chartered items first. I can understand that and support that. Deadlines are good.

Job was taken off the cc list. I added him back on. I'm sure he is on the mailing list but since he is an author I wanted to explicitly copy him (as I did Dave).

Dino

> 
> Cheers,
> Sander
>