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

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Sep 2013 21:35:49 -0700

Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file.

Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline.

Changes include:

B.1.  Changes to draft-ietf-lisp-lcaf-03.txt

   o  Submitted September 2013.

   o  Updated references and author's affliations.

   o  Added Instance-ID to the Multicast Info Type so there is relative
      ease in parsing (S,G) entries within a VPN.

   o  Add port range encodings to the Application Data LCAF Type.

   o  Add a new JSON LCAF Type.

   o  Add Address Key/Value LCAF Type to allow attributes to be attached
      to an address.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Sep 2013 04:30:22 -0400

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 know that some members of 
the WG like to have everything in one document.  But this is why we 
maintain registries.  Once we have defined LCAFs, it is quite sensible 
for documents which need LCAFs to add them to the registry, with the 
explanation of how and why the particular LCAF is beign defined.
Note that unlike base protocol mechanisms, the set of LCAFs is not 
something that all implementations need to understand.  A LISP 
implementation that is never going to do 5-tuple lookup does not need to 
know about LCAFs that are designed to handle that.  And conversely 
defining new LCAFs ought in my view create an obligation for new 
behavior in all LISP devices.  (I don't think the authors intend that 
kind of obligation.)

On a related note, I find very general LCAFs a cause for concern. 
Particular the JSON LCAF, which seems to allow the mapping system to 
reprogram the packet processing hardware on the fly seems excessive.  I 
understand it is neat for experimentation.  But how does something 
injecting a JSON LCAF have a reasonable judgment about whether the ITR 
which will receive it will be able to implement the processing required? 
  If we are assuming particular deployment models, we need to describe 
that.  (Which leads to the question as to why it is in this document.)

I may be in the rough on these concerns.

Yours,
Joel

On 9/10/13 12:35 AM, Dino Farinacci wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Albert Cabellos <[email-masked]>
Date: Tue, 10 Sep 2013 14:46:40 +0200

El 10/09/2013 10:30, Joel M. Halpern escribió:
> Firstly, I find the registration of LCAFs without any explanation of 
> how or why they would be used to be awkward.  I know that some members 
> of the WG like to have everything in one document.  But this is why we 
> implementation that is never going to do 5-tuple lookup does not need 
> to know about LCAFs that are designed to handle that.  And conversely 

This is precisely the reason to standardize a flexible LCAF, there is no 
obligation to implement all the LCAFs defined, but just the ones that 
are used by a particular ITR. Pretty much like XML and the XML applications.
> reprogram the packet processing hardware on the fly seems excessive.  
> I understand it is neat for experimentation.  But how does something 

Beyond the LCAF type, we can include a fixed size type that will tell 
the ITR if it is able to implement the processing required. From there 
we can define types that can be only used intra-domain or that are 
maningful inter-domain, again like XML applications.

> that.  (Which leads to the question as to why it is in this document.)
Fully agree with this, two of the main reasons are flexiblity and to 
reduce the deployment cost of new applications of LISP. With the 
flexible LCAF we only need to update the ITR, not the mapping system. 
This is an important barrier for experimentation or new uses right now. 
Otherwise and as you mention, we will have to face and endless amount of 
LCAF types, one for each LISP use.

Regards

Albert

>> Folks, I compiled all the input I received for updates to the LCAF 
>> draft. Find enclosed the updated draft and a diff file.
>>
>> Deadline is tomorrow but we can have discussion before I post. So if 
>> there are any changes or comments, I can add them into the -03 draft. 
>> So I am not that worried about missing the deadline.
>>
>> Changes include:
>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 08:01:03 -0700

> 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 know that some members of the WG like to have everything in one document.  But this is why we maintain

We have companion documents (that are not working group chartered documents). Here are some examples:

(1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal LCAF type.
(2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator Path (ELP) LCAF type.
(3) The draft-codas-lisp-re draft states how to use the Replication List Entry (RLE) LCAF type.
(4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for LISP-DDT-sec.

> registries.  Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined.

So I would suspect that the JSON Data Model Type would have a companion document.

> Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand.  A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs

Correct.

> that are designed to handle that.  And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices.  (I don't think the authors intend that kind of obligation.)

This is generally true but I am finding more use-cases, where people just want to store data in the RLOC LCAF encoding for easier management and network-self-documentation.

> On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive.  I understand it is

The LCAF document doesn't say how the JSON Data Model LCAF will be used so we can't assume it is for the case you state above.

> neat for experimentation.  But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required?  If we are assuming particular deployment models, we need to describe that.  (Which leads to the question as to why it is in this document.)

What we have done in two cases for similar compatibility issues is this:

(1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips over it and goes to the next AFI in the AFI-List LCAF, where low and behold, there is an address it can encapsulate to.

(2) The above is done for ELP encodings too.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Sep 2013 11:04:28 -0400

If I were writing these things, I would put the registration for each of 
those types in the companion document.  That way, a reader could judge 
the safety and utility of the proposed usage.  Otherwise, the 
registration itself is not understandable.

Asked backwards, why is there value in putting a bunch of IDs that are 
not needed in base implementation into a spec that does not explain what 
they are for?

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 08:08:19 -0700

>> On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive.  I understand it is neat for experimentation.  But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required?
> 
> Beyond the LCAF type, we can include a fixed size type that will tell the ITR if it is able to implement the processing required. From there we can define types that can be only used intra-domain or that are maningful inter-domain, again like XML applications.

It has been suggested before that we should define an LCAF type that identifies the capabilities an xTR can support. It should be clear what an ETR supports by what it registers, but one cannot tell if the ITR can use the information an ETR has registered. 

So I am not sure how this could be useful. I guess an ITR could register "I support AFI=1 and Geo only" and if the ETR registered {AFI=1, AFI-2, Geo, and ELP}, that it would only return in a Map-Reply to the ITR {AFI=1 and Geo}.

Just thinking out loud.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 08:11:58 -0700

> If I were writing these things, I would put the registration for each of those types in the companion document.  That way, a reader could judge the safety and utility of the proposed usage.  Otherwise, the registration itself is not understandable.

I found putting them in one document, as an implementor, was extremely useful. Because if I do multiple LCAF features, I want to see how the designs can work either side-by-side or integrated with each other. 

Here is an example. There is no reason that one leg of an RLE could not be an Explicit Locator Path.

> Asked backwards, why is there value in putting a bunch of IDs that are not needed in base implementation into a spec that does not explain what they are for?

The LCAF, in a coarse matter, describes what an LCAF coding could be used for. And the companion document goes into way more detail and precisely specs the operation.

Dino

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2013 21:43:55 +0200

Hi,

> 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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 11 Sep 2013 21:45:52 +0200

Hi,

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

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

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Sep 2013 11:14:50 -0700

> 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 ty…

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,…

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

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

> 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 implemen…

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